Well, with plans to have a backend for lrcdb.com, this woulud be possible. Good idea too, sure would help the database grow, and save a lot of typing/submitting for others.

Even just an option to dump the lyrics out into a .lrc file would be killer.

Even just an option to dump the lyrics out into a .lrc file would be killer.

I can guarantee that part. Soon.

I'm using lrc2sylt on linux, very useful.

I've noticed that it doesn't complain if the mp3 isn't writeable though - it appears to complete succesfully. That nearly had me tearing my hair out the other night.

I don't have an Lyric3 tags or any ID3v1. Planning for a bunch of .lrc swapping, I've been pondering the batch aspect of running lrc2sylt. I'm thinking I'll modify some perl progs I already have. I have code that builds a hash of all the mp3s indexed by filename with the path(s) to that file as an array. The idea being to run through a directory of a bunch of .lrc files, the a .mp3 by the same name and run your lrc2sylt on each file pair.

Dunno how much time I'm going to have, but if anyone else wants to start, I can send them the code I've got to use as a starter. I use it for fixing playlists, building a folder of links based on a playlist (for burning a CD that matches a playlist) and a few other things like that.

Boy I'm having problems figuring out how to get this installed.here is what it says when i install it....Installing emphatic...

C:\Documents and Settings\maistomeadows1\Desktop\emphatic-1.10>ftp -s:install-em
phatic.ftp xxxxxxxxxx
Connected to xxxxxxxxxx
220 Connected.
User (xxxxxxxxxxxx:(none)):
230 Login okay.
ftp> quote site rw
200 Okay.
ftp> cd /programs
250 "/programs" directory changed
ftp> bin
200 Okay.
ftp> put emphatic
200 Okay.
150 Opening data connection.
226 Okay.
ftp: 348756 bytes sent in 0.40Seconds 869.72Kbytes/sec.
ftp> quote site chmod 755 emphatic
200 Okay.
ftp> quote site ro
200 Okay.
ftp> quit
221 Happy Fishing.

C:\Documents and Settings\maistomeadows1\Desktop\emphatic-1.10>pause
Press any key to continue . . .
And here is what i have in my config ini file...
[hijack]
fake_tuner=1
;@EXEC_ONCE /programs/emphatic
[output]
notify=1
Did I miss something?

Can you not read in the ID3v1 tags, remove them from the mp3, then readd them without the Lyrics3 tag?

Umm why do you want ID3v1 tags? They suck.

Maybe he, like me, has some files in his collection that were tagged with an older tag editor which didn't do V2, and he doesn't want to go retagging everything just to add lyrics.

Sigh.

OK. It'll be an option.

Why not just run throught them with a program that add the id3v1 to id3v2.. i've seen a few program that will do it for you whole collection.

-Greg

Awesome! Can't wait to try it! Great work!!!

Awesome _yn0t. I tried the file like you said. The only problem i have is syncing with emplode while emphatic is an active thread. I get a media check failure I'm guessing it has somethin to do with emphatics daemon? Thanks again. For now i don't have to redo 700 lyrics over again.

Don't run emphatic from the music partition, or kill it before you try to sync.

All your prayers are answered, guys.

http://empeg.comms.net/php/showflat.php?Cat=&Board=hackers_prog&Number=142453



Except artist/title/album in LRC files. Not sure if I even want that.

BTW please post lrctool related bugs/questions in that thread. Let's save this thread for emphatic.

Actually I just thought it would be a more useful tool if it didn't do unrelated operations.

The only problem i have is syncing with emplode while emphatic is an active thread. I get a media check failure I'm guessing it has somethin to do with emphatics daemon? Thanks again. For now i don't have to redo 700 lyrics over again.

As Derrick said - quit emphatic first.

ynot - can you put this in Big Words(tm) somewhere prominent in the README? I have a feeling quite a few people will otherwise stumble on it.

ynot - can you put this in Big Words(tm) somewhere prominent in the README? I have a feeling quite a few people will otherwise stumble on it.

I'm not the only program that's subject to these problems, but yes, I will add that to the README and the web page for the next release.

Did anyone ever figure out WHY this is even a problem?

I regularly remount ro/rw filesystems while running off of them, so we know Linux doesn't care. Something in the sequence used by "sync" must be different.

??

I regularly remount ro/rw filesystems while running off of them, so we know Linux doesn't care. Something in the sequence used by "sync" must be different.

Sync unmounts the filesystems in order to fsck them. It must do so, in order for the kernel to flush data about any files or directories that fsck ends up changing.

Peter

Ahh, yes.. that was it (we all discussed this earlier, I'd just forgotten the outcome).

There actually should be no issue in fsck'ing a filesystem that is mounted RO, except that certain errors require a complete unmount afterwards to guarantee consistency with in-memory data structures.

Under most situations, this will not happen, but when it rarely does happen, we could just reboot the player afterwards instead of always requiring full unmounts.

Mmmm... I wonder if this can be done inside Hijack without confusing Emplode?

How does the player handle fsck of the / partition? If errors are found, does it reboot afterwards to ensure consistency?

-ml

Under most situations, this will not happen, but when it rarely does happen, we could just reboot the player afterwards instead of always requiring full unmounts.

Mmmm... I wonder if this can be done inside Hijack without confusing Emplode?

Confusing Emplode is exactly the problem: during a sync, Emplode is in charge of deciding whether to reboot, not the player; but we decided that having Emplode notice certain errors and reboot the player wasn't worth the risk (and it lays a heavy responsibility on the authors of third-party synchronisers: before the unmount behaviour was added in March 2001, several testers had their entire music partition wiped when fsck updated the root directory while the kernel held stale data).

Peter

How does the player handle fsck of the / partition? If errors are found, does it reboot afterwards to ensure consistency?

The player never fscks the / partition. As far as a completely-stock Empeg is concerned, the root partition is only ever written to by writing an entire disk image over it at upgrade time. "Adventurous" users who write to it at other times and by other means are assumed to be clueful enough to bear the fsck responsibility themselves.

Peter

In reply to:

---

Umm why do you want ID3v1 tags? They suck.

---

They do indeed, but it's a fact of life that some tools (eg. "tagmp3 move $pattern $file") don't read ID3v2...

Okay, that narrows down the possible solutions somewhat.

The best approach I see now is to have Hijack create a "shadow" device that overlays the disk partitions solely for the purpose of launching executables.

So things that EXEC/EXEC_ONCE launches would be launched from the "shadow" device rather than the actual (in this case) music partitions. The shadow device really just maps things to disk blocks on the music partitions, but without having the actual executables "open" on the music partitions.

That way the unmount/remount will work fine from emplode even with third party apps running. The fsck shouldn't have any effect on those apps, unless it actually relocates the data segments of the executables themselves -- which should not happen, but if it does, the executables will eventually just crash in all probability. No big deal.

Third party apps may have to be more careful with files that they open on the fly --> if they keep files open after startup then this will prevent Emplode from unmounting partitions, but I don't think this is an issue for many of them. Most apps are only really active when selected from the Hijack menu, something that generally is not done while sync'ing. GPSapp may be an exception there.

??

Third party apps may have to be more careful with files that they open on the fly --> if they keep files open after startup then this will prevent Emplode from unmounting partitions, but I don't think this is an issue for many of them. Most apps are only really active when selected from the Hijack menu, something that generally is not done while sync'ing. GPSapp may be an exception there.

??

Both GPSapp and emphatic read files, and can keep running in the background. GPSapp shouldn't be an issue for the vast majority of users - syncs are generally AC only, GPSapp DC only. And GPSapp could conceivably read the route and then close the route file (don't know whether it does at the moment or not), pretty much eliminating any problem.

emphatic on the other hand may be an issue. If emphatic is running, then it will be opening a new file for read every time the track changes. I'm sure it's not insurmountable though. I wonder, is it possible to implement the shadow device such that you could reference generic disk entries though it? And then also pass /shadow as a working directory to such apps when run from EXEC/EXEC_ONCE. Then it'd be possible to make 3rd party apps reference every file they need to read relative to the shadow, ie open "drive0/fids/xxx" or "/shadow/drive0/fids/xxx"

I don't know if this is technically feasible, but implementing a shadow of the whole fs that would be read-only and not impede an unmount of the underlying partitions would be powerful.

If emphatic is running, then it will be opening a new file for read every time the track changes.

So will the player itself. That's why playback, and thus track changing, doesn't happen during sync

Peter

True enough. IIRC, emphatic deals with tracks changes by watching the notify thread, and if playback was halted during that moment when emphatic was loading the file, I doubt that emphatic would know - I think that it only watches the notify thread for timing purposes, and wouldn't catch the halt. That raises the question of how long emphatic would take to complete the read, and how long the sync code in the player is going to wait before attempting the umount. I'm hazarding a guess that the player is only going to wait until any current cache load terminates or completes, leading to a potential race hazard if a sync is initiated just as the track is changing. (Obscure and infrequent to be sure).

Maybe I'm wrong - maybe emphatic completes the read fast enough for this to never be an issue. How long would it have?

And GPSapp could conceivably read the route and then close the route file (don't know whether it does at the moment or not)

It gets closed. Not really any reason to keep it open.

So will the player itself. That's why playback, and thus track changing, doesn't happen during sync

Can emphatic just watch the player app and close when the player app closes? Or maybe Hijack can close any executables running on the music partitions when the player app closes.