The above video goes away if you are a member and logged in, so log in now!
I noticed that SMS crashes when I have a playlist with the first song being very short (8s and 2s so far) and with ID tags, it crashes (screen goes black after "buffering" and before the bubble-player appears). If I remove the ID tags, everything is fine. Furthermore, if that mp3 isnt first in the playlist, all is well too.
Playing those mp3s without using a m3u, all it well too. Length of the filename makes no difference.
@lee99: it appears that your .avi does not contain indices, which hold frame positions. Such an .avi can not be scrolled. Otherwise you can share some fragment and I'll try to take a look;
@sigmar: feel free to share your problem mp3/m3u (I don't have any desire to make them myself );
Uploaded here ( censored by EEUG to avoid problems , thank you, I'll take a look at it) should be the mp3s and m3u's I've been working with. There should be 5 total mp3s included in the rar. Three originals, two being
repeats. The three originals contain their orginal filename, the other two have been renamed countless times to see whether their length and/or nonalphanum chars would cause any crashes (It might, but it didnt for me). Furthermore, the naming of the m3u is a bit weird, tried similar stuff with that.
Newtest.mp3 is a duplicate of 01-prelude and 01-timetimetime is a duplicate of 26-beginning.
The mp3 "bitebig" (1s) contained no ID tags orginally. It currently lists 5 as the track# for both ID3v1 and v2 spots (Im using winamp to look at this). If it is first entry in the m3u, as it is !!WA2.m3u, SMS crashes. When I remove the tags, SMS works fine.
01-prelude (8s) originally contained ID tags. When I made my playlist for the folder it was in (with 32 songs), it of course was first (being 01) and caused SMS to crash. I originally deleted all the other entries in the m3u to see if I could pinpoint if a particular entry was causing SMS to crash (I thought it was one of the songs with lots of ~ and a long filename). SMS still crashed, so I changed the first (and either only entry or first of many) to other songs (tried 3 in total, one is included in this rar) and they worked with full original ID3 tags and caused no crashes. When I made newtest (a duplicate of 01-prelude with no ID3 tags), the first entry, no problems (however newtest with tags gave crashes). When I made 26-beginning the first no problems, when I made 01-tiemtimetime the first, no problems. Both beginning and tiemtimetime have ID3 tags.
My guess from this is that the crashes usually result from short mp3s with ID3 tags. Now I dont know if it is certain ID3 tags or not, but I consistently crashed SMS with the files and m3u as-is in the rar (ie: bitebig being first with ID tags), though the other 2 8s mp3s with tags also get crashing. Hopefully you all playing around with this get similar behavior.
Furthermore, I'd like to add, just now I tried again, out-of-the-box, but with changing the ID tages for bitebig so only IDv1 had track 5 (IDv2 was left blank and unchecked), and it didn't crash. When I checkd v2 (with no info put it), it began to crash again. Uncheck v2, no crash. Now when I leave blank v1 and uncheck, and then check only v2. Crash again. So I suspect it is the v2 tags which are the problem. Bit late now, will play around with this more tomarrow.
Edit to add: Oh, I use Rad Host 1.7 pc side. SMS 1.6 rev 3. ulaunch 3.5
Last edited by EEUG; 03-03-2006 at 04:52 AM.
@sigmar: ...there is indeed a bug in SMS's mp3 code that can cause a crash in the situation you described. Thank you for your research. The fix will be applied...
Out of curiosity, what was the bug? I downloaded the source code and tried to deduce the problem, but couldn't make much out of it.
...did you tried Rev.4 already? The bug "worked" as follows:
1. Open file;
2. Check ID3 tags and skip them if they are present;
3. Check mp3 sync header;
4. Rewind file position back and start decoding <- here position was set to 0 and in case if ID3 tags are present it must be set after them. Decoder recovers in most cases, but in case of m3u there was a problem, since m3u for the player looks like big mp3, and some synchronization information are carried to the player by the first data packet read from each mp3 belonging to m3u. In case of short mp3's that information was lost because of incorrect file position...
Yea, Im messing around with rev4 at the moment. Havent noticed a problem. Most of my m3u's Ive tried worked.
Appreciate the reply, trying to understand the code at the moment for the future.
...you can use e-mail/PM if you'll need some explanations (I can't guarantee quick reply, but I'll be glad to help you out (I'm always online during workdays)) ...
Hi i have a movie wich cause some problems, it satrts well but have sound bizarre effect and jerks, is it too high quality?
Codec Xvid, MP3
Size: 640x272 (2.35:1) [=40:17]
bitrate 722 kb/s , 23.976 FPS
Audio 115 kb/s (57/ch, stereo) VBR LAME3.90 48000 Hz
@rainrix: ...I don't know . Check if it has Q-Pel/GMC and if no then try to share it (or fragment) somewhere, so I'll try to take a look one day...