Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: rosco_pc on September 28, 2007, 07:57:05 PM
-
Hi,
After installing the latest version, r14894-070928, on my F60 I get an "Data abort at 00000514"while trying to play ogg files. The files have been playing correctly before and are still playing correctly on my PC. The error also occured an earlier version, r14885 I believe, of the same day).
[edit] Added missing 1 to revision number
I went back in time with daily builds and here are the results:
r14863-070927: works
r14857-070926: works
This would rule out problems with the optimisation of the vorbis codec that where introduced. If you can point me out where to grab older SVN builds I can try to narrow i down, before submitting a bug report.
Oh I did search on flyspray and I seem to be the first with this problem. I've also tried other codec (mainly mp3) and they are working correctly.
-
Hmm... I just tried playing a 192 kbps .ogg file on my F40 and it gave me "Undefined instruction at 00000204". This is one of the files that I ran the test_codec plugin on previously without any problems.
You can find daily builds going back about a month linked from the current build page. Look for the link at the top of the page. Since no flyspray exists for this you can go ahead and file a bug report for it. I'll try to help pinpoint the revision that introduced this problem when I get some time.
Edit: I just updated to r14895-070928 and it now produces a codec failure rather than undefined instruction.
-
OK, done: http://www.rockbox.org/tracker/task/7860.
-
I went back in time with daily builds and here are the results:
r14863-070927: works
r14857-070926: works
This would rule out problems with the optimisation of the vorbis codec that where introduced.
Unless I'm misunderstanding you here, it would not rule out the mentioned optimisations because they came with revision 14875 and are only part of the daily builds since the 28th...
-
Well according to the SVN page it was submitted September 27th 21:45, so I assumed they were included in the daily build of that day (I thought that the daily build is done around midnight?)
Might it be a good idea to add the SVN version revision to the page?
edit: Time to setup the build environment again
-
The error also occured an earlier version, r4885 I believe, of the same day).
Please do only use full revision numbers -- r4885 existed but ages ago (somewhen in 2004). Omitting half of the string only makes it prone to confusion and errors --we set up the version string exactly the way we did for a reason. Revision IDs are unique ... Thanks.
-
Well according to the SVN page it was submitted September 27th 21:45, so I assumed they were included in the daily build of that day (I thought that the daily build is done around midnight?)
Might it be a good idea to add the SVN version revision to the page?
edit: Time to setup the build environment again
Midnight when? Timezones are all important!
I *think* they are done about 6am CET.
-
Please do only use full revision numbers -- r4885 existed but ages ago (somewhen in 2004). Omitting half of the string only makes it prone to confusion and errors --we set up the version string exactly the way we did for a reason. Revision IDs are unique ... Thanks.
I know that I should not respond to this, but if you had read the rest of the text you would have seen that I have used complete revision numbers. I now see that I missed a '1' in that revision number, surely you are all clever enough to see through a typo (especially as I also mentioned "I believe" and "of that same day"). The reason why I was not sure was that I downloaded a new current build and overwrote the old one (the current builds are all called 'rockbox.zip') and had not written down teh revision number as I thought I had just done soemthing wrong myself (happened before). I'll update the original psot to add the '1' (don't know how to do that in flyspray though)
Midnight when? Timezones are all important!
Correct, but the SVN page states a time when a commit is done (without any mention of timezone). I would assume that all commits done during a day would have been included in the daily build using whatever timezone the SVN commits are in as criteria.
But these are all assumptions, which are now proven to be not 100% correct.
I also got a request to try to narrow down the fault (via Flyspray), but I don't seem to be able to add comments there (I just registered myself today, at approx 7:30 Chinese time in the morning). I did not have the build environment installed on my PC so building older versions of rockbox was not possible. And I will unfortunately not have the time to do this for the coming week as I will be leaving for vacation tomorrow morning (it is here now 21:30 in).
Sorry if I sound a bit harsh, but I had a rough day at work (and a splitting headache).
-
Actually, if you think "Midnight on July 5th" all commits on July 5th are NOT in it, because Midnight happens at the beginning of the day, not the end.
-
I too await the outcome of this "hiccup".
I got a few OGG files and I keep my player on Shuffle. It sucks when it just suddenly bombs out and stops playing.
Though I am a huge mark for this gradient selection bar so I don't wanna go back.
-
I just updated to r14942 and my OGGs are now playing properly.
-
I just updated to r14942 and my OGGs are now playing properly.
Yes, I disabled the optimizations which were causing the data abort. Hopefully the code can be fixed so it also works on the Gigabeat.
-
Looks like the ASM code is linked into IRAM. You can't do that on the gigabeat since it doesn't have IRAM. The same thing happened when I committed the MAD optimizations last spring.
-
Thanks for the update guys.