Support and General Use > Plugins/Viewers

pictureflow problem - any suggestions for a fix/workaround?

<< < (11/13) > >>

amachronic:
The ramcache should kick in at boot time as long as (1) the database is built; and (2) load to RAM is enabled.

The only reason it would not load, as far as I can tell, is if there's an error in load_tagcache(). But most of those errors seem to be related to the database files being corrupted, so perhaps there's an I/O error happening somewhere.

Maybe you can try this build and post the log (system > debug > dump log file) after a failed load to RAM attempt?
https://drive.google.com/file/d/12C2IxlSvvH-AGv-ZS-cqxiQCEXv-d7m2/view?usp=sharing

Frankenpod:
I'll try that one.  Though when I tried Chris_s's build with logging enabled before, I got log files like this


--- Code: ---committing tagcache
master file open failed for R/W
commit 83080 entries...
Building index: 0
master file open failed for R/W
tag file open failed: tag=0 write=1 file=/.rockbox/database_0.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
Creating new DB
inserting new tags...
done
sorted 6084 tags
updating indices...
done
updating new indices...
done
s:0/162792/162792
Building index: 1
tag file open failed: tag=1 write=1 file=/.rockbox/database_1.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 7214 tags
updating indices...
done
updating new indices...
done
s:1/267032/429824
Building index: 2
tag file open failed: tag=2 write=1 file=/.rockbox/database_2.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 478 tags
updating indices...
done
updating new indices...
done
s:2/13120/442944
Building index: 3
tag file open failed: tag=3 write=1 file=/.rockbox/database_3.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 83080 tags
updating indices...
done
updating new indices...
done
s:3/2466776/2909720
Building index: 4
tag file open failed: tag=4 write=1 file=/.rockbox/database_4.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
updating new indices...
done
s:4/6836063/2909720
Building index: 5
tag file open failed: tag=5 write=1 file=/.rockbox/database_5.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 3484 tags
updating indices...
done
updating new indices...
done
s:5/141784/3051504
Building index: 6
tag file open failed: tag=6 write=1 file=/.rockbox/database_6.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 29615 tags
updating indices...
done
updating new indices...
done
s:6/3677784/6729288
Building index: 7
tag file open failed: tag=7 write=1 file=/.rockbox/database_7.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 1226 tags
updating indices...
done
updating new indices...
done
s:7/32112/6761400
Building index: 8
tag file open failed: tag=8 write=1 file=/.rockbox/database_8.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 41128 tags
updating indices...
done
updating new indices...
done
s:8/1415504/8176904
Building index: 12
tag file open failed: tag=12 write=1 file=/.rockbox/database_12.tcd
lookup_buffer_depth=83082
commit_entry_count=83081
Loading index file
inserting new tags...
done
sorted 6085 tags
updating indices...
done
updating new indices...
done
s:12/162816/8339720
Building numeric indices...
83080/83080 entries processed
tagcache committed
tagcache built!
tagcache check done

--- End code ---

Not sure what that signifies.  Are those errors relevant or was it failing to open the files because of existing database files still there?  It specifically never reported anything about loading to ram or even attempting to do so.
When it eventually succeeded I got:


committing tagcache
nothing to commit
tagcache: 17519324 bytes allocated.
loading tagcache to ram...

Frankenpod:

Got one more ipod to build the pictureflow index - this time it required making a failed attempt to do so (without caching the database first, so it seemed set to take hours, so I aborted it at 0% progress).  After aborting that attempt it _then_ reported it had now cached the database, so I started the pictureflow build again and this time it worked much faster.  Just rebooting the thing didn't seem to do it, nor did leaving it alone for a few minutes, it seemed to be the first aborted attempt at building pictureflow that persuaded it to then cache the DB.

amachronic:
Those 'errors' in the database build are harmless if it's a fresh database build, it's just trying to check if the file exists and if not it creates it. The part relevant to ramcache is at the end:

--- Code: ---loading tagcache to ram...

--- End code ---
signifies the start of the load to RAM. When it finishes you should see this:

--- Code: ---tagcache loaded into ram!
utilization: 99%

--- End code ---

Frankenpod:
Hmm OK.  Not sure when I eventually got the 'loading tagcache' entry - that appeared on its own in a later log file.   Tried repeatedly and got lots of log files - most attempts just didn't say anything at all about loading - certainly didn't see any messages reporting a failure at doing so, most times it just didn't seem to even try.

I guess I probably need to try logging again and be more methodical about seeing what it says specifically after rebooting or shutting down and restarting.  (Does it matter whether one reboots via centre-button+menu or shuts down by long-pressing play then restarts?  Is there a difference between the two?)

The most recent attempt gave a whole different error message - despite correctly loading the DB cache to RAM, this time it got to the end of picture flow indexing and then said something about 'unable to load empty slide'.  That might be something hardware-related about that particular ipod, maybe? [Edit] That one worked on the second attempt!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version