So while my car was offroad I decided to properly tag all my mp3's, delete all the music off my mp3, and upload the retagged files, along with a bunch more onto my mk1. There's about 10,000 songs totalling around 50gb, and I had to do the upload in 2 parts as emplode would refuse to upload the music otherwise.

I had a few problems with syncing and the building database message taking for ever, so I followed the instructions in the FAQ and that seems to be resolved now, however the empeg refuses to play anything. If I choose a song, or a playlist or whatever, it appears to all work fine, but when I go to play it it displays the play symbol, but never actually begins to play the song. The counter doesn't change, the progress bar doesn't change, for all purposes it appears to be paused, but it's not.

I'm running hijack 508, the serial log appears fine, although ever time a new song is loaded I get the message:

spindown_chunk_cache_runner.cpp: 294:Filling up space (-17)

Although the number in the brackets changes.

Does anyone have any suggestions? Hopefully I don't have to wipe the disk and start again, it takes a LONG time to upload that much music onto a Mk1

Cheers,
Adrian

I've a nasty feeling that this is a symptom of your (newly enlarged) database taking up so much of the player's music cache, that there's none left for actual music cache data. Do you have a "ReserveCache" setting? If so, reduce it by at least 17. (If you don't know whether you have one, then you don't.)

The music cache is particularly small on Mark 1 players (which of course have only 8MB RAM altogether rather than the 12 or 16 of later versions). If you've hit its limit then there's not a lot you can do except slim down your music collection.

Peter

Thanks for the prompt reply

I thought that that might be the problem. Is there anyway I can check the database size? The database file in /empeg/var is 1517160 bytes. I'm not aware of any ReserveCache setting, so I'm guessing I don't.

The database is the same size in memory that it is on the disk, I think. Or at least only a small factor bigger. According to me six years ago, the Mark 1's cache size is 2.5MB, so your 1.5MB database shouldn't actually be a problem. Umm, 1MB left for caching, say 200kbits/s, 25Kbytes/s, that's 40 seconds. That won't be enough to ever spin the disk down, but it shouldn't be so little that it can't play at all.

Of course, it's not much use not being able to spin the disk down; that's just a recipe for drive failure when used in an actual car. Really for a collection that size you should be thinking about a Mark 2 or 2a.

Peter

So sure enough I deleted a handful of the albums I'm least likely to listen to, and now it's working again. Thanks very much for your help peter, although I can't help but wonder now how many more songs I can fit on there before i reach that limit again.

Just out of interest, the only way around this would be a memory upgrade correct? What is the story with the database with ID3 tags? If I prune all the comments and garbage out of them, will that shrink the database? Does the empeg use ID3v1 or v2 or both to generate the database? If this is all in the FAQ I apologise, I did have a read through to try and fix the problem, but I don't recall seeing any of this information here.

I'd love to get a Mk2(a), unfortunately they're always a little out of my price range. I got my Mk1 for a song, so I might as well use it until it finally gives up.

Yes, if that's even possible on a Mark 1 (and even if it were, buying a Mark 2 would probably be cheaper).

The story is, Emplode decides what goes in the database. When you drag music files into Emplode, it scans the ID3 tags (v2 if present else v1) to produce the default tags; if you subsequently edit the data in Emplode, whether before or after synchronising, then it only changes the database, not the ID3 tags.

Yes. In fact, if you clear all the comments (and other fields you don't use) in Emplode, it'll shrink the database size without touching the ID3 tags.

The theory was, only ID3 tags used by the player software get put in the database. But in retrospect, the usefulness of comment tags in the player (I think they appear in the About Track screen? if at all?) isn't really enough to justify them being in the database and thus permanently-resident.

Peter

Okay cool, I've just cleaned out the Comments, Year and Genre of all the songs, since i never search by those anyway. Hopefully that'll give me a little extra space next time I put some more songs on.

Thanks again for all your help, i really appreciate it

That's how I remember it. But you're right that they're essentially useless and should be removed.

In support of that idea, deleting the 1 or 2 dozen albums freed up about 100kb, while pruning the tags on the remaining songs freed up an additional 300kb

Someone correct me if I'm wrong, but wouldn't another way around it be to split up the collection into smaller playlists, and play just those playlists?

i.e., I'm assuming he only runs into the problem when trying to shuffle the entire music collection.

No, that wouldn't solve the problem.

Unless I've misread, the problem happens even playing a single file. The symptoms (including the telltale "-17" remaining chunks) match only a cache exhaustion, not exhaustion of any other area of memory, including the running-order.

Peter

Yeah, Peter's right. Everything is in playlists of Artist, then Album, so at any given time there's usually only a dozen songs being played, and the error was appearing when trying to play even a single file.