• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System iPod Nano
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Rockbox
Opened by DeeKay - 2007-12-09
Last edited by Buschel - 2011-07-27

FS#8287 - Bugs in Rockbox SIDplay

This is all tested on a 1st Gen iPod Nano 2GB, so I don’t know if it’s a Nano-specific prooblem or a general one:

1. Rockbox hangs on “Loading…” when selecting a SID from the filebrowser when another one is playing in the background. Background-SID continues to play though. Doesn’t happen all the time, but fairly often, just try it a few times!

2. Metadata isn’t interpreted sometimes, it just shows the filename and “???”. Happens mostly when you skip through a folder with files quickly using back/forward in the player-screen itself. Just try it for a while. Sometimes it switches back and forth between showing the metadata and not showing it.
Once this happens, Metadata isn’t shown anymore until the SIDplayer is re-launched.

3. Sometimes (I’ve only seen this twice) the first letter of the Artist isn’t displayed. It just uses a space instead. Possibly a badly coded stringcopy-loop? No idea how to provoke this unfortunately

If anyone needs SIDs:

Closed by  Buschel
2011-07-27 18:36
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

THis was fixed with the rewokr of the playback engine.

Project Manager
zagor commented on 2007-12-14 12:43

“Sometimes” is a very bad word in bug reports. I can’t repeat any of these problems on my C200. We need to be able to trigger the bug to fix it.

Hmm, atleast 1) and 2) was very easy to reproduce on my iPod nano. I’ve just installed the latest daily just to make sure it’s not been “accidentially” fixed in the meantime, and lo and behold Bug 1) is fixed now (I haven’t seen  bug 3  in quite a while, too, i must say!). I tried very long to provoke it, but no way. Awesome! ;-)

Bug 2) remains though. after skipping back and forth quickly for a while the Metadata is fucked up. Sometimes it’s not shown, sometimes it shows the wrong info for the tune playing (happens both with metadata showing and unidentified) and I’ve noticed another problem: The first tune in a folder seems to be problematic. I’ve seen RB actually reducing the total number of tunes listed while skipping through the directory for a while, and at first the first tune couldn’t be played, then the second, then the third. When wrapping around it would then start with Tune 4 in the directory, really weird!
One more thing i found out: Once the metadata-parser is fuxX0red, it doesn’t even work on mp3-IDtags anymore, you have to reboot RB. Metadata for “Next tune” is always shown correctly however, both in SID and mp3!

Also, some tunes just won’t play. In the attached file this would be 2400_AD.sid (which is also the first file in the directory) and savage.sid. Unlike the fifth_axis.sid someone else mentioned (which loads, but doesn’‘t play), they won’t even load. I’ve also noticed that Deel_3.sid takes a very long time to start, maybe that’s the same cause as with fifth Axis?
I did notice that for the SIDs in question (2400/Savage) there are normal versions and PSID versions in the HVSC. TinySID on OSX refuses to play the normal versions, too (”unsupported format”), but it plays the PSID versions just fine!
And Fifth Axis only plays silence on the “big” TinySID, too, so it’s not a Rockbox problem! ;-)

Can anyone with an iPod Nano confirm this? Some more infos about my environment, maybe this helps: I have a load of Jeroen Tel Tunes (and some others) in a folder in the iPod root called /SIDs. See attached file if you wanna try yourself!

If you send me some debug-enabled version or sth i could easily reproduce it and send you the log! ;-) (107.6 KiB)

Your second bug sounds like it could be a more general playback/metadata issue, where skipping back and forth rapidly might confuse it. Maybe some input from Nicolas Pennequin is in order here?

Edit: In fact, it sounds an awful lot like  bug 8320 , so maybe this should be closed, and you could open a new task purely about the sids that won’t play?

Yeah, that sounds a lot like it - but what I am experiencing that he doesn’t write about is the non-displaying of metadata. Maybe that is just a consequence of this “going out of sync” problem that only shows in SIDs, not mp3s?

Although the problems with skipping around quickly seems to have been fixed with other codecs, the SID player throws a “codec error” and will stop playback ad spit you back out to the menu. This is very easy to reproduce on the e200 w/ r17071 and a playlist of 4 tracks, skipping backwards and forwards a little bit very quickly.

The 2400_AD and savage SIDs also do not play for me.

Another interesting bug: Play the last song in the folder from the file tree, stop it, and go back one directory, there will be folders missing/hidden on top even though there is room to display them all.

I think the main problem discussed here are the RSID files wich are not supported by the tinysid engine. In DeeKay’s attached file there are exactly three files wich are RSID and not PSID: 2400_AD.sid, Myth.sid and Savage.sid (just have a look at the first four bytes in the file to find out).
I confirm Fifth_Axis.sid does not play but as this is a PSID file this seems to be another problem that should be discussed seperately. The windows tinysid player has no problem with this file, maybe a later version in RB would solve that. The long start up time of Deel_3.sid is no RB problem, in sidplay2/w the delay is there too.

But back to the RSID issue. I use an ipod video simulator with version r24777-100219 but the behaviour is the same on my real ipod video 30G.
When i directly select an RSID file the whole system hangs and nothing (even mp3’s) is played any more until RB is rebooted! This is really very annoying and should be fixed quickly!
If the RSID file is between some others in a sid directory it is just skipped. This happens with myth.sid for example:
the file order in the dir is JT_in_Space.sid → Myth.sid → One_Tear.sid, if you select JT_in_Space, the wps shows One_Tear as next track and will play it if you jump to the next track. Also stepping back to JT_in_Space is no problem.
But if the RSID file is the first one in a directory this does not work any more: select Alternative_fuel and step back to previous file (2400_AD) and we have our nasty bug again :(
Maybe interesting: when stepping to an rsid file, the current file plays on, stops after 1-2 seconds and the simulator says “sdl_audio_callback: No Data.” I’m not sure if the RSID issue has something to do with metadata parsing, maybe it is just a deadlock in the interaction of codec and playback thread because tinysid refuses to play rsids and the api does not ecpect that? I fear someone has to debug that…

When i delete the rsids i do not have any problems even when skipping tracks very quickly - maybe these things are fixed in the meantime.

btw: some people here (DeeKay :) asked for pseudo stereo playback of sid files? See

I did some debugging with debug outputs in sid.c and got some new information. Here is the difference between good and bad sids.

A sid is playing normally as precondition.

case 1: the next sid in the queue is not playable. The get_sid_metadata() function for all sids in the queue is called in advance and the corresponding call for the unplayable sid returns false.
skipping forward to next sid is done and sid.c:codec_main() receives:

  ci->new_track --> ci->request_next_track --> the sid behind the unsupported one in the queue is played 
  -->  everything is fine

case 2: an unplayable sid is selected directly in the file menu. get_sid_metadata() returns false (and maybe true for following ones in the queue).
sid.c:codec_main() receives ci→new_track (and breaks its while(1) loop) but not ci→request_next_track(), then the codec_main() exits with CODEC_OK as expected, but this will f**k up whole playing logic as written above.

I’m wondering how the codec api can set ci→new_track while ci→request_next_track() returns false afterwards? And when it does so, why has it such a problem when the codec_main returns?
When I change the return value of codec_main from CODEC_OK to CODEC_ERROR, playing will not hang, but then there are some other strange problems (e.g. wps background is completely black). As this is not recommended in the codec structure template, this cannot be the solution.
The sid codec does not seem to do anything wrong here. Maybe this is a design problem in the codec api?


Available keyboard shortcuts


Task Details

Task Editing