Thanks for the pointers, that got it to do just what I wanted!

Now I just need to sit back and wait for it to tag all 14K songs They're hosted on a linux file server, but with Gigabit ethernet to my PC, the network isn't the bottleneck.

I like the option in there to overwrite the first 0.03 seconds of audio with the new v2 tag, but I'm not in a hurry... I'll just let it run all weekend.

If someone happens to have Simon and Garfunkel's "Hazy Shade of Winter" and emphatic already installed, perhaps you might humor me and get the 2 files in ftp://lrcdb:lrcdb@ftp.lrcdb.com/dbrashear/?

The one with "broken" in the name seems to quickly display something when it should display "Leaves are brown" at about 24 seconds in, then erase it. If I don't tag a blank line after it, as in the non -broken version, it's fine. A quick reading of the code doesn't illuminate what the problem is to me.

I'm going to do some more extensive debugging tomorrow, but I was mostly wondering if anyone else sees the same.

Hrm. Same results here. I get the same results with "And look around" at ~0:46, "Look around" at ~1:10, and "at the sky" at ~1:51 with both versions of the LRC. No immediate idea what the reason is.

One variable here is that you've got a lot of blank lines. Not that they should matter, but they're really making the scrolling do way too much... scrolling. You know? Why put in all those lines that it has to re-calculate scroll speed so much (even though it's not adding any text.) I think without all those extra lines, the scroll speed would be a little more stable, because it wouldn't be adding in extra space so much. My algorithm tends to throw space in to try to get the current "line" across the screen and also give you some space in between lines. Putting the blank line is putting this gap in twice, not necessary if you ask me. Still, my program shouldn't be having lines disappear just because of this, though in all instances I mention above, the "problem line" that's quickly disappearing is immediately preceeded and followed by a blank line (but so are other non-problematic lines in the song.)

<sarcasm>Why do I have a feeling this is going to be a really fun problem to debug.</sarcasm>

Some of the blank lines are needed for the (short) instrumental portions, IMO, but the rest were there just so it looked sane in the XMMS singit plugin. (which highlights a line, then moves to the next one, in this case a blank, when that hits.)

Nothing seemed special about the just over 1 second delays between the lyric before, the blank line, and again to the lyric after; Not even something that should reduce to the same timestamp.

I was actually doing to use some printfs and debug to stdout.

I wasn't saying the lines were causing anything here, it's just something I noticed.

Hmm, short instrumental portions shouldn't need a blank line... I mean I did suggest using a blank line for much longer solos, etc. just so the current line doesn't scroll too slow. One improvement I hope to make (though it's not an easy calculation) is to have the scrolling target column 64 (the middle of the screen) instead of column 128 (the far right.) The problem is I have to begin drawing the next line prior to the moment the current track time hits that line's timestamp, but depending on the speed of the current line, that delta time (between when I draw the next line at column 128 and when that next line becomes the "current line" at column 64) is different each time. I haven't yet struggled with trying to make it work just right, and I'm not sure it'll be trivial.

So once I (hopefully) implement that, you should not need so many of those blank lines to make sure the words are on the screen at the right moment. The current workaround is to call emphatic with a -o parameter, say, -o 1000000 to have it start scrolling the next line a full second before it's supposed to -- that way, the line is somewhere closer to the middle when we hit that line's timestamp.

Anyway, this is tangential, I just don't want to see everyone adding hundreds of blank lines to their lyrics just because they don't line up correctly. I still have no leads on why the lines are disappearing for you, but I'll continue to look into it (probably not today though.) If you find something, let me know.

I wasn't saying the lines were causing anything here, it's just something I noticed.

I would actually guess the lines were causing it. I pruned a bunch of them now and am about to go get lunch. I'll see if that worked, and look at it some more later.

Would anyone care to speculate why I'm not able to sync with emphatic running? I'm not running it from the music partition; it's in /usr/local/bin. With the last version of emphatic, I was running it from the music partition, found out it broke syncs, and moved it. Now, with the new version, it's broken again, even though it's not anywhere near the music partition. I get the same fsck error as if it was. Help!

What else do you have running from the music partition?

Incidentally, after a fsck failure I got into a situation where one of the music partitions never fscked cleanly, and fsck appeared to be dying because it was out of memory. Instead of trying to determine what was going on I killed the player (after making sure init couldn't respawn it) and fsck'd by hand. I probably should have figured out what was actually going on. Nothing was running from the music partition, but something had been on the first fsck that failed.

What else do you have running from the music partition?

Haha. Funny. The answer is, nothing at all. My steps to reproduce are very simple: comment out ";@EXEC /usr/local/bin/emphatic" and I can sync. Uncomment it and I can't.

Umm I wasn't trying to be funny, but okay...

I'll try to reproduce this at home tonight. But if it turns out it prevents syncs, the easy solution is to quit out of emphatic before you sync, no?

Nothing I'm doing is causing this, and I can't detect when you're going to sync your player, so even if there was something I could turn off during sync, I'd have no idea when to do so.

These gripes about syncs are really starting to get to me.

No, I know you weren't, but it certainly would have been funny if I had been running something else from the music partition that was the culprit.


I don't know if you'll be able to reproduce it, since no one else has reported any problem yet. For everyone else, if they can't sync, they just move it out of the music partition and all is well. The only reason I'm having problems is because of the curse on me, my family, my house, and my descendants for as long as my line shall extend.

If you don't mind showing me a serial log of what happens when the sync fails, that would be helpful in diagnosing the problem.

I don't know whether or not this well help, but I'll manually fsck all the partitions and see if that catches anything that wasn't caught before. I'll report back in an hour...

oh, well that explains it. you should have mentioned the curse in the first place.

--dan.

For some reason I get the idea that I should build lsof for the empeg.

Sheesh do I now need to disclaim myself from damages resulting from a prior curse???

For some reason I get the idea that I should build lsof for the empeg.

Actually that seems quite helpful, if not for this problem, than for some other ones I'm sure. But, is there any way to get information like that out of the kernel without something like lsof? One of the /proc entries perhaps?

Does the arm linux distro contain "fuser"?

If you uncomment that line the player tries to read the @EXEC line which it can't, only hijack can. You should leave this always commented out, it should work commented out because that is how hijack expects it.

Hmm. I interpreted "comment out" as "added an extra semicolon" meaning it would be
;;@EXEC

If he was removing the semicolon, then yeah, that'd be a problem.

Yeah, I meant add an extra semicolon

Okay, running an fsck of everything manually doesn't help anything. It still fails to sync.

Here's what happens: I initiate a sync. Emplode gets as far as "Checking Media: Waiting", then after a few seconds, gives "Synchronize failed while checking media. Error 0xc0041010".

In the meantime, the serial output is thus:

Adding Swap: 16596k swap-space (priority -1)

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

ext2fs_check_if_mount: No such file or directory while determining whether /dev/

hda4 is mounted.

hijack: removed menu entry: "emphatic"

Restored terminal settings

Remounting first music partition read-only

Remounting second music partition read-only

Restart code received

Starting player



hijack_exec("/usr/local/bin/emphatic"), rc=0 (okay)

Using non-standard cache size 102 (adjustment 32)

opening display...

starting notify thread...

notify thread started (tid=1026)...

lyrics thread started (tid=2051)...

emphatic v1.10 (built Feb 18 2003 20:15:18) running as pid 43

  player.cpp        : 385:empeg-car 2.00-beta13 2002/07/24.

Prolux 4 empeg car - 2.1434 Jul 24 2002

Vcb: 0x4066d000

Basically, fsck poops for some reason and the player restarts.

Any more ideas?

Any more ideas?

Just to cover the obvious, /usr/local/bin isn't a symlink to someplace on your music partition is it? Some people may not understand the distinction (or lack therof).

-Mike

I certainly don't recall making it that way, but checked anyway, and it's not.

So what's in /etc/fstab?

The ext2fs_check_if_mount is going to be no mtab file because / was mounted ro and so it couldn't be created. The other thing you could do is from a shell on the player:

rw
(mount each filesystem in /etc/fstab so an mtab entry gets created)
ro

try sync again


but i don't know why this would matter.

So what's in /etc/fstab

And while your at it, what is the output of 'cat /proc/mounts'

-Mike

Here's my /etc/fstab:

#
# /etc/fstab
#
# <device>    <mountpoint>   <filesystemtype> <options> <dump> <fsckorder>
/dev/hda5       /               ext2          defaults,ro    1      1
/dev/hda4	/drive0		ext2	      defaults,ro    1	    1
none             /proc          proc          defaults

I don't recall modifying this ever, so this should be what the player was installed with. I can't fully follow the grammar of your post, because I think there must be a typo in there. But, it seems like you're saying that an mtab file's not getting created, and that's because / is ro? And that might be something causing ext2fs_check_if_mount to fail?

I'm connecting to the player via ethernet right now, but I'll try to force the creation of the mtab entries the next time I drag the player into the dungeon to connect to serial. I'll report if that changes any behavior at all.

You can create the mtab entries with a shell via ethernet.

rw
mount -o remount /dev/hda5 /
mount -o remount,ro /dev/hda4 /drive0
ro

cat /etc/mtab and see if it's reasonable. it should be something like:
/dev/hda5 / ext2 ro 0 0
/dev/hda4 /drive0 ext2 rw 0 0

And here's /proc/mounts:

/dev/root / ext2 ro 0 0
none /proc proc rw 0 0
/dev/hda4 /drive0 ext2 ro 0 0
/dev/hdc4 /drive1 ext2 ro 0 0

Nothing looks out of the ordinary to me, but I don't really know what I'm looking for. Poking around elsewhere in proc, am I going to find anything that indicates what files might be open? Like if I look at the PID for emphatic in /proc, is anything in there going to tell me anything? I ask because /proc/41/fd/ gives me:

dr-x------    2 0        0               0 Feb 26 02:40 ./
dr-xr-xr-x    3 0        0               0 Feb 26 02:40 ../
lrwx------    1 0        0              64 Feb 26 02:40 0 -> /dev/ttyS1
lrwx------    1 0        0              64 Feb 26 02:40 1 -> /dev/ttyS1
lrwx------    1 0        0              64 Feb 26 02:40 2 -> /dev/ttyS1
lrwx------    1 0        0              64 Feb 26 02:40 3 -> /dev/display
lr-x------    1 0        0              64 Feb 26 02:40 4 -> pipe:[45]
l-wx------    1 0        0              64 Feb 26 02:40 5 -> pipe:[45]
lr-x------    1 0        0              64 Feb 26 02:40 6 -> /drive0/var/config.ini

Does this mean that emphatic has config.ini open for some reason? Or does this show something completely unrelated?