I've been fine with jemplode 45 for weeks up until now, and upgrading to 52 doesn't fix the problem, which is - on launching jemplode, the app downloads the database and then freezes with 98% CPU activity on "updating interface"

I've been looking at sirmanson's thread about jemplode 47 to try to work out what's wrong, but I can't. I think it may be a either a dodgy playlist or song - how can I check? Emplode 2.0 final still works fine. I'm on Hijack version 334.

Just so you know, I tried updating to hijack 355 - same problem. Any ideas...?

i had this same problem. i had a playlist that was screwing up emplode (it would crash whenever it displayed it on screen) and jemplode did the same thing you say its doing.
read here for information on how i fixed it

In the next build I'll add more debug statements in to see if we can figure out what in the world it's doing at that point ...

Hi,

It's difficult for me to determine what the problem is, as I can't get emplode to crash yet. Did you have to go through each and every playlist to do this? Problem is a lot of mine are soups based on searches, so there are hundreds and hundreds of them - [play_count > 1, by genre, artist, album] etc. I could always blow away the soups after noting what the criteria are, and then recreate them (I only have a few static playlists) - will this be necessary?

i dont play with soups, so im not sure how theyre displayed, but if you do a search for refs>=0 it should show everything on the empeg. then, scroll down. if it crashes you narrowed it down pretty close, provided you were watching where (alphabetically) it crashed at. of course, yours may not crash at all. you may have to wait for his more verbose jemplode build

From your method, I've nailed it down to a playlist called "slow", fid 1723 (6bb hex). I went in via ftp and deleted 6bb0 from drive1/fids, started emplode and synchronised, shut down emplode, restarted, scrolled down the list of everything (refs >=0), and the f***ing thing is still there and crashes emplode! What do I do now??? I'm nearly there, I know - it's so frustrating... I am very grateful for your help so far.

did you set the filesystem to rw before deleting and then to ro after?

yes!

is there another file? The one I deleted didn't contain the playlist's contents, which were visible when I did a csv export from emplode.

is there another file?

I don't know if playlists have both a *0 and a *1 file or not...

Also, is there a chance that the problem is with a song that lies within the playlist as opposed to the playlist itself?

Playlists have a *0 and a *1. The *0 contains a list of fids in the playlist.

hyperterminal in
grep for the offending name and delete whatever rears its head

Any idea what would cause a playlist or song to be "damaged" like this?

Half a fid paid going away for indeterminate reasons, I guess:

-fsck removed it?
-bug causing only one of the 2 files to go away?
-crash between the 2 files going away?

Pretty wild possibilities but they are improbable, not impossible.

I think it's got to be the playlist itself. The crash doesn't occur when I scroll down the view of "All Tracks". I'll have another go now...

Went in via hyperterminal, blew away database and also 6bb0 fid which I'd missed in drive1/fids. One database rebuild later and... everything works again!!! Thanks again everyone (customsex especially) - what a relief....

cool
glad i could help