Rockbox

  • Status Unconfirmed   Reopened
  • Percent Complete
    0%
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System iAudio X5
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Arioch - 2008-10-21
Last edited by Buschel - 2011-04-21

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

also category:
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]

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?

It just does nothing, and it begin to show track rime as
so, until reboot every other track i would try to play is also shown as 0:00 - 0:00 - all tracks are treated as
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
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
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,
- same - Rockbox is not moving through the track, as it usualy does when playing. Hence - no advancing =⇒ no
- differs - triggered by track FF/Rew at unlucky time span, rather than specific file
- differs - fixed by changing track, no need to
- 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.

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.

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.

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.

Patch committed. Lets see if it fixes all problems.

Re-opened on request by dmitry.


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


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


<folder

last>

All folders contain some album of some band from jamendo.com (ogg torrent downloaded (though their torrents are awful :-(
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
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 0×00. 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
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
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
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 ?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing