Support and General Use > Plugins/Viewers
pictureflow problem - any suggestions for a fix/workaround?
chris_s:
Pressing the Menu and Center buttons force restarts your iPod, which you’ll want to avoid.
Do you experience any data corruption when using Rockbox’s USB mode? That seems like a litmus test for when to expect issues to pop up in normal operation as well, and may indicate that the combination of iPod classic and the iFlash adapter or SD cards you’re using may be still be causing issues with Rockbox.
Frankenpod:
Good question, though I don't really know, as I've always avoided using rockbox's USB mode, precisely because, at least in the early days, it was very likely to cause corruption. I get the impression that's improved with more recent versions of RB but I've continued to avoid risking finding out. (Really don't want to risk ending up with a file system corrupted to the point where I have to restore the whole thing completely)
Currently picture flow is working well on multiple ipods. Will try again installing the logging version and see what's going on with loading DB to RAM. Never got any actual error messages in the logs about that before, though, it just either did it or, more often, seemed to not even attempt to do so.
Been repairing cover art for all the albums (on the computer) where it's missing or is too large/wrong format to be displayed. Looking through pictureflow it becomes easy to see all the art that is, for example, in embedded png format or has some other problem. Once your improved 'update' work is in a dev version I'll have a go with installing it and resyncing then updating the picture DB (and see if it does it in reasonable time).
Frankenpod:
Really noticeable that it makes an order-of-magnitude difference to the speed of building pictureflow indexes if the database is actually cached to RAM. Still can't quite work out what persuades it to actually do that. Sometimes it's just a case of leaving it alone for a while (during which time the disk-activity indicator is shown - maybe it just takes a long time to read the whole thing from the flash storage?)
I haven't been able to test the revamped "update cover art" option because until/unless the increased buffer-size patch gets merged the later dev versions won't work for me due to that running out of memory issue. Unless I can get dev environment working again and build my own patched version, of course.
chris_s:
--- Quote from: Frankenpod on May 23, 2022, 11:41:04 AM ---Really noticeable that it makes an order-of-magnitude difference to the speed of building pictureflow indexes if the database is actually cached to RAM. Still can't quite work out what persuades it to actually do that. Sometimes it's just a case of leaving it alone for a while (during which time the disk-activity indicator is shown - maybe it just takes a long time to read the whole thing from the flash storage?)
I haven't been able to test the revamped "update cover art" option because until/unless the increased buffer-size patch gets merged the later dev versions won't work for me due to that running out of memory issue. Unless I can get dev environment working again and build my own patched version, of course.
--- End quote ---
to tide you over... :D the latest dev build with a 2mib plugin buffer: https://www.dropbox.com/s/8at7v4jzd10webm/rockbox-full-ipodclassic-2mib-plugin.zip?dl=0
With a database of your size, I would expect at least a few minutes of waiting time until everything's loaded into RAM after booting (with both dircache and tagcache in RAM) – and possibly much longer – which is what led me to the "solution" I mentioned in one of my previous posts, which speeds up that process quite a bit. Maybe I can turn that into an official option at some point: https://forums.rockbox.org/index.php/topic,54031.msg250401.html#msg250401
Frankenpod:
Thanks again, that's very helpful. Been experimenting with that build - does certainly _seem_ as if it makes the picture-flow build process faster still, but it's hard to quantify for sure, because there still seem to be a great number of (I suspect iflash-mod-related) glitches to deal with before getting to that point, so I didn't get to time it methodically. (I feel like, once database was built and loaded to RAM, it took about 10-20 minutes for the whole picture-flow prep process, rather than the 30 minutes it took previously, but forgot to note the time it started!)
Had problems updating the database to start with (before could even get to picture flow) because - and it seems as if having 'load to RAM' set to on is related to the problem - the database has an annoying tendency to take ages to build, and then mysteriously disappear and have to be rebuilt again - particularly after a shut-down/restart. Plus there's the usual issue of getting it to actually load into RAM (seems like it requires a shut-down/restart and then a long wait while keeping an eye on the disk-activity icon..._if_ the database doesn't disappear entirely with the shut-down)[Edit - nope, seems even that doesn't do it reliably...sometimes it does, other times no matter how long you leave it the thing just sits there and makes no effort to actually load the DB].
Once working though it's quite impressive being able to flick through so many albums of cover art.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version