Emplode Random Song Destruction: 2.0beta11, Hijack 276

In one case, after a Wendy Flag edit (probably inside of a Soup View
before I found out that doesn't work), during syncing I got a warning
about a playlist having an inconsistent number of children. (A
playlist unrelated to the ones I was doing wendy flag edits upon.)
Sure enough, I look and a song (Track 3) is now missing from the
middle of the album and the sequence numbers of the following tracks
have been renumbered to move them up to fill the gap.

The good news is that the database consistency checks caught it.
The bad news is that this is a worrisome bug and I probably haven't
given enough information to be able to track it down.

I don't remember hearing this one before, so I'm adding it to the internal bug list.

I experienced this problem again, under slightly different conditions, so I thought I'd add the info here.

This time, an album playlist was deleted, and I got the warning about the parent playlist (the artist) having an inconsistent number of children. However, the songs on this album were not deleted and I was able to recreate the album playlist by copying from the Soup view.

Here's the important difference about triggering the bug.
I wasn't editing Wendy Flags this time; I was correcting an artist name misspelling. And I definitely was NOT doing the edit in a soup view, since those edits seem to be flaky and/or non-sticky. So the bug seems to be related to doing a multi-select, and then editing a field to be applied en masse. Afterward, an unrelated playlist was deleted. Perhaps some sort of overrun problem in the attribute modification code?

Also, here is some weird stuff from my boot log in case it has any bearing on this (doubtful). But let me know if I should be concerned about this for other reasons.

First, some disk detection problems:

Tried to mount /dev/hda4 as reiserfs but got error 19
Mounting second music partition
Tried to mount /dev/hdc4 but got error 6
Error mounting partitions (possibly already mounted)
Remounting first music partition read-only
Remounting second music partition read-only

Then an error at entrance to the player:
! mp3_decoder.cpp :1049:Failed to find valid sync after seeking to offset 2267
281, error=0xc0044000

The later error reappears if I drop into the shell and then "exit" back to the player.

Neither of these problems seem to adversely impact the normal operation of the player, however. As far as I know, they've always been there.

Also, for what it's worth, when this occurred, although the sync did not hang and succeeded (except for the warning message), the dirty flag did not get reset and Emplode asked me if I wanted to sync again when I exited.
This is probably Working As Designed since there was a warning reported.

This is all rather strange stuff and might indicate a problem with the player.

However the "reiserfs" error is normal, so that doesn't mean anything. The other stuff is weird though, I'd contact support if I were you.

Does the new 2.0 kernel have reiserfs support compiled in? That could be cool. A faster, journaled filesystem...

Has anyone tried newfs'ing any of their fs's to reiserfs?

It's not implemented ENOUGH to actually use it on the car player if I recall correctly. I think 2.0 has the code partially in there as an experiment for another related product (don't remember if it was the HSX-109 or not).

Do a BBS search on reiserfs to find previous discussions on the topic.

No, reiserfs is not compiled in, and nor would it work with the kernels versions the player uses.

Cheers

I got a random deletion again. This time without doing a multi-select to trigger it, which I thought was the key.
But I was doing about a 700MB download, which is reputed to be iffy in beta11 according to the FAQ.

The exact error is:
The length of playlist BLAH did not match the actual number of children detected.

Interestingly one of the *other* errors (the decoder.cpp error) went away.on its own.
I was all ready to reinstall beta11 and hijack to see if I could make it go away. Then I checked and it was gone.
It seems to intermittently reappear from time to time. (Ummm, I guess that *is* the definition of "intermittent.") but I haven't determined if it is due to the contents of the database (i.e., if syncing new files makes it go away) or if it is more hardware related and it just appears on some boots and not others.
Now that I'm out of room and won't be downloading any more tunes, I can check into it. (Yes, I need a new hard drive, but I'm not about to violate my warranty until I make sure this is not a hardware issue.)

I got a random deletion again.

Have you reproduced it on beta 13? Has anyone else seen it?

one of the *other* errors (the decoder.cpp error)

As Tony says, that's not really an error. The next version of the software won't report any error for that situation.

Peter

Have you reproduced it on beta 13? Has anyone else seen it?

I haven't had a chance to try it on Beta13, as my player is full and I won't be
adding songs or messing with Wendy Flags again until I upgrade my drive
capacity (which should be within a month or so).