Rockbox General > Rockbox General Discussion
buggy dircache activity renders ipod almost completely unresponsive
surfer:
I have about exactly the same issue as described by squidkidd with my Ipod 80GB since about a week ago after installing a new "current build". With the newest one from today, 17617, it is the same thing: it scans for about 5 minutes with "resume playing" as the start screen, during this time Ipod is almost unresponsive.
When "resume playing" turned off it takes considerably shorter, about 30-60 sec.
dip:
I have the same (or at least a similar) effect with my ipod 80GB with the current build.
I do not have the resume playing option turned on but when I turn on my ipod and then immediately start browsing the database the hard drive gets spinning like crazy and the ipod is unresponsive for a long time (about 2-5 minutes). When I first wait until dircache is initialized (takes about 30 seconds) then browsing the database is no problem. When I start browsing the file tree instead of the database immediately after I turned on my ipod (of course after the menu appears) then the ipod remains responsive.
So it seems that the problem with the competing hard disk access seems only appear between initializing dircache and using the database.
TexasRockbox:
I do not have the latest build (r17588) on iPod 5.5G 80GB, 12,000 .ogg files and have noticed similar behavior. On bootup the hard drive seems to be thrashing incessantly when playing the first song (and it is not from a "resume") and music will even cut in and out every few seconds. When skipping to the next track (whenever that is -- usually immediately) the continuous disc reading will stop and then behavior seems normal.
surfer:
Today i went through older builds and found out that the 'scanning bug' is definitely there (again?) beginning with the IPOD build 17469 from the 12th May 2008.
Everything seems to be OK until the build 17451 (2008-05-11).
So it seems to be one of the builds between 17463 and 17469 that introduced the bug. Where can i get those current builds to check which one excatly it was?
Please take a look and verify:
http://www.rockbox.org/daily/changelogs/changes-20080512.html
jhMikeS:
??? I think this problem has to be investigated out the context of always blaming threading which seems to be the common default position. No signs have ever pointed to any sort of scheduler bug as the root cause and any bug like that would cause similar behavior across all ports. The 30GB 5.5G that uses large sectors had no issues.</end defensive spiel> 8)
I know that increasing the ATA powerup delay fixed the issue of the core hanging during an interrupt wait for at least two main reporters of the issue (and a Nano owner). Perhaps it needs still longer for the large HD or another power issue still exists in regards to the disk.
NOTE:
Of course things like dircache or database updates taking alot longer with playback running are expected since it's placed in the relative background to favor CPU for decoding audio. If they run basically alone, they get pretty much all the CPU time.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version