This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9502 - Freeze when playing multi-track OGG files
Attached to Project:
Rockbox
Opened by dmitry (Arioch) - Tuesday, 21 October 2008, 21:18 GMT+2
Last edited by Andree Buschmann (Buschel) - Thursday, 21 April 2011, 20:09 GMT+2
Opened by dmitry (Arioch) - Tuesday, 21 October 2008, 21:18 GMT+2
Last edited by Andree Buschmann (Buschel) - Thursday, 21 April 2011, 20:09 GMT+2
|
Detailsalso category: ID3
---- Some containers, like Matroska MKA or like Ogg can contain numerous audio tracks, for example the whole AudioCD contained within single Ogg file. For example VideoLAN.org plays such files ok, while fails to show separate tracks/tags in playlist. However, RockBox justs freezes and until reboot can no longer play music (each file is detected as having zero duration) example can be found: [link deleted - it was a full copyrighted album] |
This task depends upon
Can you provide more information on exactly what happens when you try and play such a file?
More so, until reboot every other track i would try to play is also shown as 0:00 - 0:00 - all tracks are treated as zero-length.
One may assume that then Rockbox should blaingly fast skip through all the tracks - no, it keeps standing on any one of them. Maybe there is soem delta, minimus step within track, that akso is calculated to zero, so Rockbox enters into some kind of for (x=0:00; x<=0:00; x+=0) infinity ?
Rockbox reacts to controls, UI shows changes between Play|Pause, etc. And X5's remote control can keep thse infamous clicking sound. Just duration is zero, position is zero and sands still w/o sound. Perhaps i could enter debug menu to have some detailed info, but i guess you can easily reproduce the case.
PS: You may like example or not, but i don't think you would easily find more examples on the net. Free music is hardly distributed on media, and ripping any media for upload makes it infringing as well.
Any example file you would search for in the wild - would be infringing. You would hardly have any example chained-ogg file to debug RockBox and legally clean at the same time.
PPS: RockBox playback (at least on X5) is somehow fragile. I frequently have similar iissue when skiping tracks near its boundaries. Track length is detected ok, but position is not changing and no sound. I can navigate inside song - but after i changed position it would stand still. I don't know if that is related much, but
1 - same - Rockbox is not moving through the track, as it usualy does when playing. Hence - no advancing ==> no sound.
2 - differs - triggered by track FF/Rew at unlucky time span, rather than specific file format
3 - differs - fixed by changing track, no need to reboot
4 - differs - track length is not shown as 0:00
PPPS: what i here describe as track length, is rather "time left to play until end of song", however at 0:00 position that is the same as length.
Regarding your chained ogg files, I first tried a chained ogg file mixed in with a directory of other files. As expected, Rockbox skipped the chained ogg and moved to the next track.
I then created a directory and put two chained ogg files in there. I can confirm that Rockbox does indeed freeze.
So the bug doesn't appear to be specific to chained ogg files - I'm assuming that whenever Rockbox has a playlist full of files that the metadata parser rejects, this happens.
When playing a directory with one invalid file, and one valid file, both files appear to remain in the playlist, but only the valid track is played.
I've only tested it in the UI simulator so far (where I couldn't fully re-create the problem), so more testing would be good.
And we'll see if this would affect bhaviour, that linustb called the second bug. Has it some correlation or not.
Could not reproduce with GUI sim
Sometimes it still gets stuck in duration-zero way. However most times the resul is quite weird. Instead of displaying error, Rockbox chooses some other file to play.
Example one:
<folder>
<folder>
....
<folder-last>
chained-ogg
At attempt to play chained ogg, Rockbox delays for quite a bit, then suddenly jumos to play folder-last/mp3-last (yes, it descents into folder)
Example 2:
<folder 1>
<folder 2>
...
<folder N-1>
<folder N>
<folder last>
All folders contain some album of some band from jamendo.com (ogg torrent downloaded (though their torrents are awful :-( ))
Since those are different bands, then tag database is not reated (in the exampe one that might be not folder descending but rather database cursor moved. Here i think no such possibility).
<folder-last> contains almost zeroes - as i said tracker at jamendo.com is awfull, so 2 days and night i downloaded nothing for that album and all files, ogg|txt|jpeg, are streams of 0x00. Mea culpa, i was not atentive, when copied. So i guess it counts as heavily damaged ogg-file to RB.
When i attempt to listen for something from folder-last, RB brokenly skips through 4 files there and... starts playing (usually) ../folder-N/ogg-last (yet once i saw ../folder-N/ogg-first playing and once ../folder-N-1/ogg-last)
Yet when i said playing, that means it is what shown on display. Usually RB get into that duration-zero mode and plays nothing untill reboot.
Screen shows zeres and question marks, so file format is no detected as well, not only duration.
Perhaps if to post System|Debug OS Stacks or buffering thread - bu how should i do mem-dump then ? Or at least screen-dump, will i enable it - what to do next ?
I see lamost no strange there, except for a number of zzeroes in buffering thread and 96% of stack for tagcache thread.
As well i see "dircache info" as 'not initialised' and "database info" as 212% progress (initiaised and 100% in normal working mode).
Since dircache thread is right above of tagcache, i think that may be that stack overfow of tagcache pollutes variables of dircache, but there's no database thread and i can't see what had polluted its variables.
BTW, does X5 provide MMU, protected RAM accross threads ? May it be the difference, that GUI sim separates RAM of different threads, so thread (even if not beeing killed due to AV) cannot affect other threads in sim, and easily corrupts them on rea X5 hardware ?