My player hangs when I start the root playlist. The hourglass icon appears and then the player stops responding, both on the panel and remotely. Nothing appears on the serial port when the player hangs. I first noticed this when I upgraded to 20b3 but did not post this problem, assuming someone else would.

Now I see the problem remains in 20b7, and I also can't find any similar posts.

None of these options seem to matter

consumer or developer image

car or home operation

shuffle or no shuffle

rebuilding the database

I also created a named playlist containing all songs. This playlist hangs too. All other playlists play fine.

My two Travelstar 30 GB drives are almost filled with over 10.000 songs.

The next thing I'd try is reformat all drives and reinstall from scratch, but I'm reluctant to do that. I just might end up hitting the same problem (some limit?) again.

Any other ideas?

Thanks and happy new year,
Pim

I've also got two 30GB drives but am running the same root playlist (shuffle and no-shuffle) procedure without a problem. I've got just under 5900 tracks, so that may be your problem.

Then again, your problem may be one or two problem tracks. Try this:

Make two root-level lists, each with half your tracks. Now play each, one at a time to see if either hang. Of course if they both hang then it gets trickier. You'd then do another binrary division, but make the split somewhere else. Or divide into four lists, etc.

Bruno

If you can find a problem track (as Hybrid8 suggested), make sure to save a copy of it in case it's something the empeg people can look at.

I'm assuming this only happens with the 2.0 betas and does not happen with 1.03?

Also, have you performed a synch since upgrading to 2.0b7? Some known problems were solved simply by synching once after the upgrade.

First, has anyone else got a similar number of tracks on their player? Are they having success?

If you feel confident with a terminal program and zmodem, grab a copy of the database, tags and playlist files from /empeg/var. Zip 'em up and bang a copy over to us, and we'll take a quick look to see if there's anything fishy in there.

Here are some facts about my player that mey help finding a resolution for my problem. Some are answers to questions asked elsewhere in this thread.

database structure

My songs are structured in playlists this way:
/first letter of artist name/artist name/album name/song name
So the root playlists contains just playlists called A to Z and one playlist containing all the artists my girlfriend likes.
I rebuilt the database putting all artists in the root and discarding the A-Z playlists. It did not help.

database

The size of the database on the player is 1.136.456 bytes. I've made the the database available for download here. You can find an XML export of same database there too.

non-beta player versions

Non-beta versions play the root playlist just fine. I reverted back to 1.03 and I had no problem playing the root playlist. No resync was necessary. Reverting to 1.03 and the upgrading back to 2.00-beta7 is not fun. I lost a lot of settings among which all tuner station frequencies.

I was considering staying at 1.03, but then I would suffer the "reboot on tuning to Dutch radio 1" bug. And of course, there would be no way to fix the problem.

resync

Resyncing the player under 2.00-beta7 does not help. I already did that; it is what I meant with "rebuilding the database".

not fully dead

When my player hangs, it is not fully dead; the thread that is shifting track titles left and right because they're to long to fit keeps working.

player messages

My player produces error messages on the serial console. This message usually pops up at the same time the player starts to play:

! mp3_decoder.cpp   :1052:Failed to seek to offset 5214899, error=0xc0044000

! mp3_decoder.cpp   :1047:Failed to find valid sync after seeking to offset 5214899, error=0xc0044000

This message seems to appear all the time. Sometimes the player hesitates when these messages occur. The last number (31 in this example) varies.

  spindown_chunk_cache_runner.cpp: 292:Filling up space (31)

my MP3's are not perfect

I use Jack to rip my CD's. Older versions of jack (actually older versions of the ID3.py python module) had a bug that would overwrite the tail of a non-tagged MP3 file rather than append the ID3 tag.

Technically these files are corrupt, but the corruption is inaudible. But it might be the new player MP3 codec barfs on these MP3's.

determining maximum playlist size

Now this was the hard part. I tried to create lots of playlists with different sizes at once to see how big they could get. I created playlists called A-B containing A and B, playlist A-C containg A, B and C, playlist A-D containing A, B, C and D and so on. I was thinking I could just try to play all of them until the player would crash, without the need for doing resyncs, which takes a lot of time with 60 GB of data.

But having this many nested playlists makes the player very unstable. It would crash almost immediately at the very first keypress. The console reported the player was killed by VM. It did not look like a memory shortage; adding swap did not help.

So I deleted all these playlists and created one playlist that I continued to add "letters" to until the player would crash playing it. I came to "R" until the player crahed, but unfortunately this crash was not a player hang, but a harddisk crash. One of my Travelstar 30GB's would refuse to spin up after making some ugly noise. This happened just after one of many power cycles.

One strange thing I noticed was that after adding more one-letter-playlists to my test playlist and resyncing, the player seemed to play the old playlist with the old number of songs in it. Only after re-selecting the playlist would it show the correct number of songs.

My Travelstar was still under warranty, I sent it to IBM using the warranty procedure on http://www.storage.ibm.com/hdd/support/pre_rma.htm

When I get a replacement drive, I will be able to continue my tests. So far, I have come to a playlist of some 6800 songs without hanging the player.

BTW, I was considering buying the new 60 GB Travelstar, which costs only a couple of Euro's more than the 48 GB model. Has anyone tried the IBM Travelstar 60GH?


Pim

I've made the the database available

Thanks, I'll try to take a look at this today.

One strange thing ... Only after re-selecting the playlist would it show the correct number of songs.

This is correct. At the point you select a playlist, the FIDs contained in it are added (or inserted or whatever) to the running order. From this point onwards, the player doesn't know where they came from. This means that it won't spot any additions to the playlist. It also won't spot any deletions (unless you delete the track completely).

Nice and detailed bug report, Pim.

I'm also seeing the same problems with 2.00b3 and b7.

I have a 4gb Mk II that's about a year and half old. It also has about 10,000 songs on it and has about 200mb of free space left.

When doing a random play on the entire playlist I get the same lockups. Usually it displays the info screen for the first (random) song, but then never plays. The disk activity icon is there with the activity "light" on. I've waited up to two minutes to see if it ever recovers but it doesn't. Sometimes button switches work but usually the unit is hung up right at that spot.

If I power cycle the player then it's usually fine and plays the song that came up first in the random play list.

I've re-synced the player numerous times since I'm currently going through my entire 600 CD collection and re-ripping the entire collection to VBR, adding the year to the tags and fixing all the other tag problems.

One thing I've been planning on trying (but keep forgetting) is to limit the size of the random playlist. I remember that you can edit the properties of the playlist to only include a percentage of all songs in the random playlist. Thus I could set it to only use 10% of the total songs when creating a random playlist. Since I never get THAT far into a random play before selecting something specific it shouldn't alter my play style at all.

I'll let you know if that helps.

David Schmidt

Heh, that's funny. I made a ripper front-end named "Jack" a couple years back, too. What a coincidence.

I had this exact problem - admittedly with only 3000 tracks and it had me stumped for ages. Would hang on selecting root playlist, although all tracks/albums etc could be individually selected or played - no corruptions (well, a couple, but just audio glitches)


My brother came up with the fix - it was to do with the playlist properties. The upgrade to 2.0beta7 seemed to set all of them to the 'play 1 selection' option (can't remember what it's actually called and I don't get home from work for a couple of hours yet) but new albums I added allowed for full selection. I simply selected the root playlist and chose the other option in properties.


I'll edit this later with the correct property name.

I too see the

  spindown_chunk_cache_runner.cpp: 292:Filling up space (110)

error often. Sometimes it will be 1 a seconds for about 5 seconds, then it might not happen for 10 minutes. Last time I happened, I rewound and listened to the same spot it did it last time and nothing happened... then later it did it where it had not happened before... doesn't seem to be related to that part of the song.

While rewinding (after not seeing any errors for ~5min), I see this:

! mp3_decoder.cpp   :1052:Failed to seek to offset 9810231, error=0xc0044000

  spindown_chunk_cache_runner.cpp: 292:Filling up space (110)

  spindown_chunk_cache_runner.cpp: 292:Filling up space (110)

! mp3_decoder.cpp   :1052:Failed to seek to offset 9763949, error=0xc0044000

  spindown_chunk_cache_runner.cpp: 292:Filling up space (110)

! mp3_decoder.cpp   :1052:Failed to seek to offset 9737263, error=0xc0044000

  spindown_chunk_cache_runner.cpp: 292:Filling up space (110)

I've got a MkIIa running 2.0b7 with hijack 151. Nothing else (e.g. vncserver) is running.

The "Failed to seek to offset" and "Filling up space" messages are simply debug-display information in the beta. They are not errors and do not indicate a problem.