Warning: mysqli_real_connect(): Headers and client library minor version mismatch. Headers:50625 Library:50543 in /sites/rockbox.org/flyspray/adodb/drivers/adodb-mysqli.inc.php on line 108 FS#9502 : Freeze when playing multi-track OGG files



FS#9502 - Freeze when playing multi-track OGG files

Attached to Project: Rockbox
Opened by dmitry (Arioch) - Tuesday, 21 October 2008, 19:18 GMT
Last edited by Andree Buschmann (Buschel) - Thursday, 21 April 2011, 18:09 GMT
Task Type Bugs
Category Codecs
Status Unconfirmed   Reopened
Assigned To No-one
Operating System iAudio X5
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


also 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

Comment by Dave Chapman (linuxstb) - Tuesday, 21 October 2008, 21:53 GMT
Rockbox should detect chained Ogg files and refuse to play them. Due to their design (or perhaps lack of design), it's not feasible for Rockbox to play them, or even to just play the first track.

Can you provide more information on exactly what happens when you try and play such a file?
Comment by dmitry (Arioch) - Wednesday, 22 October 2008, 20:43 GMT
It just does nothing, and it begin to show track rime as 0:00-0:00
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.
Comment by Dave Chapman (linuxstb) - Thursday, 23 October 2008, 19:41 GMT
Please try and keep this task related to a single bug. If you have found others, please open new tasks (but search first). I'm limiting my reply to your first bug ;)

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.
Comment by Magnus Holmgren (learman) - Thursday, 23 October 2008, 20:58 GMT
This patch hopefully fixes the playback problem, or at least one problem I saw: if no good file is found, the playback engine isn't stopped properly. In the simulator, that simply left the WPS "hanging" at 0:00, but pressing stop and playing another track worked fine. The patch should stop the playback properly if no good file is found.

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.
Comment by dmitry (Arioch) - Friday, 24 October 2008, 18:00 GMT
will there be special build for X5, might be interested to try.

And we'll see if this would affect bhaviour, that linustb called the second bug. Has it some correlation or not.
Comment by Magnus Holmgren (learman) - Sunday, 26 October 2008, 20:16 GMT
Patch committed. Lets see if it fixes all problems.
Comment by Magnus Holmgren (learman) - Monday, 17 November 2008, 17:42 GMT
Re-opened on request by dmitry.
Comment by dmitry (Arioch) - Monday, 17 November 2008, 19:12 GMT
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:

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 ?