Support and General Use > Plugins/Viewers
pictureflow problem - any suggestions for a fix/workaround?
Frankenpod:
I can't build the database for pictureflow, because it goes for ages then fails with an 'insufficient memory' error. The error is more specific than that, it refers to a particular kind of memory, but without spending ages letting it run again I can't remember what the exact error message was, sorry.
I presume it's because this is a flash modded ipod and has a lot of tracks (> 10,000) so a lot of cover art.
Alternatively, possibly it's to do with the usual problem with writing to the drive on flash-modded ipods...but my impression is that has gotten a lot better with later dev versions (this was using a very recent dev version, i.e. within the last couple of weeks...it seems more recent versions are more stable than RB used to be when it comes to building the database on modded ipods, for example, so I'm wondering if now the problem with pictureflow is simply what it says it is - too much cover art for the allocated memory?).
Does anyone have any ideas as to how to work around this?
I might try a test with an iFlash ipod with not many tracks on it, to check if it really is just a matter of too much cover art for the plug-in to cope with.
Bilgus:
Pictureflow uses the remaining plugin buffer to create the list of tracks and then writes it to a database file
I recently rewrote it to do t :o :(his in in stages likely it's just out of space..
We could probably stop playback and take the audio buffer too if it's not already doing that
During building
I don't remember if the album art is resized before pf copies it but if so that could be an issue
Frankenpod:
I notice there have been some fixes to pictureflow by Chris_s recently. Would those relate to the kind of crash I was getting? i.e. is it worth trying again with a recent dev version of rockbox? Or were those fixing some other, unrelated, bug/crash issue?
On a related note, as there seems to have been a lot of changes (some reverted?) to both the database handling and pictureflow in recent dev versions, I don't suppose there's any chance anyone would do an update of the Windows-application simulator builds (as downloadable under 'extras')?
Perhaps that's asking a lot as I guess it would be a lot of work to build those for every player. But the changes to the database code means that one can't now use the simulators (as currently available) to build the database on the PC and copy it to the device.
(I notice at least at one point, the database lost the separate artist/album artist tag choices...curious what the reasoning for that was. It's not a big deal, though usually I'd prefer to use the 'album artist' tag, as it avoided including entries for large numbers of ultra-obscure artists that I just happened to have one lone track from on a compilation album - making it easier to find the artist I was actually looking for...and conversely, sometimes I'd use the 'artist' field, if I was looking for one of those obscure compilation-album-only artist tracks.)
chris_s:
I don't think my PF fixes will be helpful with respect to the crashes you were getting building the album index. Have you tried using smaller artwork files as Bilgus, I think, alluded to? I have about 17k songs and neither the iPod 4g nor iPod video (both modded using an "iFlash-Solo" adapter) seem to have trouble building the index on device (although it takes a long time and I have to make sure the device doesn't go to sleep in between) with 160x160 JPEGs.
As for the album artist entry, I'm with you, it's also been discussed on IRC and Gerrit. Like you said, PictureFlow at least has been reverted to using album artists again. Which may mean, although I could very well be wrong, that the old Windows Simulator applications can once again be used to build a PF database for the latest dev builds... I don't know who'd be able to update them otherwise..
Frankenpod:
Thanks (and thanks for your ongoing work on Rockbox).
I guess I could try shrinking the artwork files - would have to set up some series of scripts to extract all the embedded art, then resize it, then re-embed it, much as I did when purging all the .png format art, but it would be a bit of effort and haven't got round to trying it yet. Presently most of the art is about 300x300 pixels, not sure how much shrinking would be needed to get picture flow DB to build - and I'm not certain a memory-shortage issue is the only problem there anyway.
When it gives an error message (right at the very end after taking an absolute age to go through the stages of building the pictureflow DB) about 'insufficient memory', is it referring to onboard RAM, or does it mean it's having trouble writing stuff to the flash card?
Navigation
[0] Message Index
[#] Next page
Go to full version