I've been trying to put the finishing touches on emphatic 2.00, and I've hit a snag that seems to be more of a problem in player v3 than in v2. The problem comes when I try to read the playlist and running order data that gets written to /dev/hda3. In v2, this data, including the current playlist length, running order entries, etc. seemed to be updated within a short period of time from when you selected a new playlist. But in v3, there seems to be a delay of up to a full minute between when the user picks a playlist and when the contents of hda3 change in response to the selection. I'm guessing this was done for some kind of performance reasons, but the net result is that all the stuff I read from hda3 is outdated for up to a minute. The end user will see the old track and playlist data until the player writes this stuff out.

I don't reckon I'll have any success asking for this behavior to be reversed, as I'm sure it was changed for a reason. I guess my appeal to the empeg folks is to get some other way of getting this information in a more current fashion, perhaps by writing stuff out on the console. So, if there's any way possible to get the following things written out on the console in an upcoming release, it'd help me a lot:

When a new playlist is selected, inserted, etc.:
- Current playlist length
- Current running order length

On track changes
- Next 5 FIDs (current FID is already available, the next 5 would let me do Now & Next display.)

If this data were written to the console, the kernel could eat it up and stick it in /proc/empeg_notify, which I could look at instead of going to hda3 directly. Without it, I can't think of another way I can find this information with any sort of confidence that it's current.

Kind of a strange request, I know, but I thought I'd put it out there... The notify data seems to change periodically anyway.

I've seen this take more than a minute. I changed playlists shortly before arriving somewhere earlier only to see it revert when I got back into the car later. Annoying...

Yeah, that's happened to me too, so I kinda had a hunch this might be the problem. For v3 at least, I'm going to have to get the current FID number from empeg_notify, but it seems the FID # in empeg_notify is broken with Hijack v374 on a v2 player... So I will have to keep my existing method of finding the current FID from the hda3 data if I'm going to keep compatibility with v2 players.

Does doing a sys_sync() (before accessing hda3) help?

If sys_sync() is what's accomplished with the "sync" command, that doesn't help. It seems that whatever mechanism is deferring the write is managed by the player and not the OS.

I actually caught up with Roger on the IRC channel earlier today, and he informed me there had been some work done not too long ago to make deferred writes work properly on the Karma, and offered that as a possible explanation. In this case, deferring the write on the empeg causes playlist amnesia when power is yanked in the in-between time. Dunno if this is new with a7 or has been around awhile, this is certainly the first I've seen of it.

in the v3 alphas, i've been doing a set bookmark to get force a write to the dynamic partition everytime before i turn off my car. i just set it as a hijack IR macro. if your program can send IR Codes to do the same, then you can force a "sync" just fine.

Ooooo... very clever!