Okay, v82 of the popular "Hijack" Empeg enhancements is out.

Hijack is an easy to install kernel replacement for Empeg/RioCar players running the v200beta (any beta version) release software from Rio, featuring a separate menu system with a number of user-designed user-implemented enhancements gleaned from this BBS. If you have not installed it yet, you are really missing out!

Features include: selectable "automatic volume adjustment", "countdown timer" (for sleep or wakeup), high temperature alarm, IR-Translations for third-party remotes (or even for redefining the "stock" remote), ..., and of course, the "Break-Out" video game. All in a single download, installable by even the most phobic of users.

The latest version v82 has two new features over v81:

-- a new "Restore DC/Car Visuals" menu entry allows the player to power up with visuals re-enabled when in "car mode", the same as normally happens when in AC/Home mode.

-- a new option in config.ini can be used to revert the menu displays to the original "classic" style used prior to v79 (?). Some folks wanted this, but most of us will probably just stick with the new default style. To get the original behaviour, stick this into config.ini (using Emplode):
[hijack]
old_style=1

Get your copy now from http://rtr.ca/empeg/

Cheers

-ml

Ok, since you like prompt replies, here is my test:

Set Restore DC/Car Visual to ENABLED
Forced the AC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Set the info mode to Transient
Forced the AC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Back to Track info mode, rather than Transient.

Either I'm doing something wrong, or v.82 does not work properly. Tomorrow I'll try in my car and let you know.

Thank you, Mark, as usual! Now, knowing you, I am tempted to stay awake and wait for v.83, but since it's 3.20 in the morning here, I'd rarther go and rest. So, take your time!

Is it me or does this version cause the "Favorite Visuals" button combination (holding down the Visual buton on Rio Remote) to not work anymore? It worked for me before upgrading. Any chance this would cause a problem with that feature?

Favorite visuals works for me, running v82.

In reply to:

---

Set Restore DC/Car Visual to ENABLED
Forced the DC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Set the info mode to Transient
Forced the DC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Back to Track info mode, rather than Transient.

---

I assume you meant "Force DC/Car mode" (no such thing as "AC/Car").

Ahh.. but I have an idea. My changes & testing were against beta3 and beta6(internal), not beta7.

beta7 has that nifty new info mode for dialing a position within a track (forgot the name of it), which probably mucked everything up for this.

Too bad. Maybe I can detect which beta is running and do the appropriate thing for beta7 versus earlier ones.

Okay, so it's broken on beta7. Wait for v83 to fix it, or run beta3 instead.

I don't run beta7 here anymore.. just too buggy compared with earlier betas.

-ml

Okay, if you're running beta7, then the new feature of v82 won't work yet.. I'll fix it for v83, I hope.

Meanwhile, I need beta testers for another new feature: init sequences.

On my server (http://rtr.ca/empeg/testing/) is a v82.5 ("restore visuals" still broken for beta7), which includes a first cut at "initial button press sequences" for car/home.

Syntax is the same as for regular IR translations, except that the "old" button is given as "initial" instead of an actual button code, as in:

[ir_translate]
initial=xxxxxxxx,xxxxxxx

Also new in v82.5 are the ".C" (Car) and ".H" (Home) qualifiers for translations, valid only on the left of the equal sign. These can be used with regular translations, as well as with the "initial", as in:

[ir_translate]
initial.C=xxxxxx,xxxxxxx
initial.H=xxxxxxx,xxxxxxx

Or even more complex:

[ir_translate]
initial.CR=xxxxxx,xxxxxxx ; only if in-car with radio active
initial=xxxxxxx,xxxxx ; all other times

One restriction: only a single "car" and a single "home" initial string can be specified.. if more than one is found, only the last one is used.

Somebody please try this out and get back to me (email) at mlord@pobox.com
I have not even tried it myself yet.. no time.

Cheers

-ml

I f***k**g dislike the way this BBS interacts with my browsers!!!

Anyway, after several "stale" edits, the previous posting with this subject line is now "correct".

Please reload/reread it if interested.

-ml

Sorry Mark, Yes, I meant DC/Car obviously. It was 3.20 am, as I said
However, Yes, I am using b7, that's why it was not working. I forgot to mention that.

It seems that there is a bug in the actual v82 hijack kernel implementation:

On all the menu entries generated from userland applications (EMPEG_HIJACK_WAITMENU ioctl), the last character of each entry isn't displayed.
In my case "RDS TMC Receive" instead of "RDS TMC Receiver" is displayed.

I'm running 2.00b7.

Can anyone else confirm this?

I can confirm it.
I've now fixed it in my internal sources, look for it in v83 later today.

-ml

Favorite visuals works for me, running v82.

Doh... Could it be that you're on 2.0b3 and I'm on 2.0b7? When I hold down the visuals button, instead of getting the "favorites visual mode on" message or whatever, it flashes up with the current info mode (it doesn't actually change the info mode, it just beeps and shows "Info: Transient" or whatever.)

I'm stumped on this one.. sigh.

doh.. no, I tryed et un bata sephen ass well.

Works fine on hijack v82 and v83 on beta6 and beta7.

-ml

Okay, Hijack v83 is now available from http://rtr.ca/empeg/

This version has several features of interest:

-- "restore visuals" now works with beta7, so the player can now power-up in-car with the visuals/info mode that was active at last power-down (car or home).

-- a new menu item allows disabling the "casual" filesystem checks that happen by default every 10th (?) sync or so.. these are pretty much unnecessary, since the filesystem checks will still be done anyway whenever there's really any trouble (like a failed sync), and they just add an unnecessary delay of 5-25 minutes at sync time.. so I like to turn them off ("disabled") on my player.

-- IR translations can now be different for "Car" and "Home" operation, using .C or .H "modifiers left of the equal sign in config.ini, as in:

xxxxxxx.H=yyyyyyyy
xxxxxxx.C=zzzzzzzz

(not 100% tested yet, but I think it works now.. let me know).

-- support for "initial=" IR sequences for startup. Not tested, but I think it should work: please test and let me know A.S.A.P., as in:

initial.C=xxxxx,xxxxxxx,xxxxxxx ;; car mode initial button press sequence
initial.H=yyyyyy,yyyyyyy,yyyyyy ;; home mode initial button press sequence

or

initial=xxxxxxx,xxxxxx,xxxxxx ;; initial button press sequence for both car/home


-- the Radio Data Service (RDS) patch is now integrated into Hijack, courtesy of René Vogt .

-- the beginnings of "notify=1" FID interception are in place, but not functional yet.. Soon.

Cheers

-ml

"restore visuals" now works with beta7, so the player can now power-up in-car with the visuals/info mode that was active at last power-down (car or home).

Yep, working for me with 2.0b7. Thank you!!!

Tom

Note that the spelling of several "Favorite Visuals" has changed in beta7, and the player software seems to ignore the old spellings.. if none of your spellings match the new spellings, then the feature may just get disabled.

??

-ml

-- a new menu item allows disabling the "casual" filesystem checks that happen by default every 10th (?) sync or so.. these are pretty much unnecessary, since the filesystem checks will still be done anyway whenever there's really any trouble (like a failed sync), and they just add an unnecessary delay of 5-25 minutes at sync time.. so I like to turn them off ("disabled") on my player.

And the crowd goes wild! Huzzah!

Testing now..

No, I don't think that's it.. I went to sync tonight and noticed all of my settings had been screwed (IP address, name of player, owner info, etc.) This morning I noticed that the Visual Names were showing on visual change, when I had disabled that on my player. Upon further inspection, my entire config.ini was a blob of binary data. I don't know if this was due to a bad sync, or me powering down without unmounting /drive0 (I don't remember this happening) or what... But anyway I thankfully had a backup of config.ini lying around. Once I replaced it, things worked fine.

Then I tried to re-enable the "show visuals on change" to see if that was the culprit, and it isn't. So I guess the mangled config.ini caused some kind of problem.

I just hope nothing else on my drives was lost. I'd love to know what happened to my data, I'm hoping this isn't the start of (gasp) hard drive troubles. /dev/hda is about 15 months old.

Another symptom of the messed-up config.ini was that my IR translations weren't working... Is it possible that Hijack chokes on a really mangled config.ini and stops working? I was still getting the hijack menu, but no IR translations.

Welp, no joy here on the restore visuals thing. Observations:

1. When the player boots into tuner mode, nothing happens at all. I switched to "transient" mode in tuner and when I restarted, it came up in the "Radio" info mode (no visuals.)

2. When booting into player, I wa in transient mode and when restarting, it sent two quick "Info change" commands but unfortunately that put it into "Info: Off" instead of Info: Transient. Maybe this has to do with the fact that 2.0b3 doesn't have the "Seek" info mode?

I was in a hurry since it was freezing outside when I tested this, so I might have been a little hasty in my testing. But I'm pretty sure these two things aren't working exactly right.

In reply to:

---

1. When the player boots into tuner mode, nothing happens at all. I switched to "transient" mode in tuner and when I restarted, it came up in the "Radio" info mode (no visuals.)

2. When booting into player, I wa in transient mode and when restarting, it sent two quick "Info change" commands but unfortunately that put it into "Info: Off" instead of Info: Transient. Maybe this has to do with the fact that 2.0b3 doesn't have the "Seek" info mode?

---

Well, I suppose #1 above is expected -- I haven't tested in Tuner mode, cuz my tuner is at home and I won't be back there for a few days yet.

As for #2.. not sure. I have tested with beta6 (internal) and beta7. Beta6 also does not have the "Seek" info mode, but perhaps there's some other difference. I'll retest perhaps when I get a chance, but it should work with beta7 as-is.

Thanks for the quick testing!

-ml

PS: and standby for v84, with /proc/empeg_notify for FIDs and other stuff.

>Is it possible that Hijack chokes on a really mangled config.ini and stops >working? I was still getting the hijack menu, but no IR translations.

Yes. Hijack STOPS reading from [ir_translate] at the first sign of a syntax error. You can tell what it likes by looking at the serial output.. only the accepted translations are echoed back.

Cheers

-ml

Okay, v84 is out.

Two changes:

(1) the countdown timer has been revamped; setting it is now easier.

(2) Hijack now creates and maintains /proc/empeg_notify on the player. To use this, you must first add this to config.ini:

   [output]

   notify=1

The data shown in /proc includes track name/fid/position/artist/album/etc.. the same as dumped to the serial port by notify=1.

Now the 115200bps question.. should I hack it some more such that the data is generated regardless, but only gets released to the serial port if notify=1 is in config.ini?? Doing it that way would be nicer (no load on the serial port), but it has potential to confuse other apps using the serial port with similar strings..

-ml

I am getting an entry "empeg_no" instead of "empeg_notify" and it doesn't contain anything. I'm getting the serial output, though... Maybe the serial output is different?

here's a sample of the serial output..

  serial_notify_thread.cpp: 116:@@ N0

  serial_notify_thread.cpp: 117:@@ F0xef10

  serial_notify_thread.cpp: 118:@@ TThose Damned Blue Collar Tweekers

  serial_notify_thread.cpp: 119:@@ APrimus

  serial_notify_thread.cpp: 120:@@ GModern Rock

  serial_notify_thread.cpp: 180:@@ #ef10  0:00:00

  serial_notify_thread.cpp: 170:@@ S0

And my /proc directory with v84 installed..

1   48       cpuinfo       empeg_power  ide         meminfo     slabinfo

16  49       devices       empeg_rds    interrupts  misc        stat

19  5        dma           empeg_state  ioports     mounts      swaps

2   7        empeg_cs4231  empeg_therm  kcore       net         sys

21  audio    empeg_id      empeg_usb    kmsg        partitions  tty

3   bus      empeg_ir      filesystems  loadavg     scsi        uptime

4   cmdline  empeg_no     fs           locks       self        version

I agree with your idea, only output stuff if notify=1 in the config.ini for hijack.
[this lets us end-users configure our config.ini ourselves and set either notify=1 in the normal player section of config.ini and have the player S/W output the notify info as it does now, or notify=0 in the normal place and notify=1 in your section to have the modified version output which includes the fid].

You of course always build the /proc entry for current fid, playlist etc etc -regardless of players notify= entry - that way software using your kernel will always be able to rely on the information there.

For apps that use the serial port themselves, they simply ensure/check that notify=0 in both places in the config.ini where it could appear.
[and presumably fail softly/warn the user if they are not both 0 as it would be fighting with another data stream on the serial port if it ignored these settings when either or both was 1]

My 2 cents.

The only apps that could be looking at the serial interface for this data ("serial_notify_thread.cpp: ") realistically would be external apps (ie, outside the empeg) like the video display generator from a while back. They'd have to set notify=1 anyway and live with the consequences.

Anybody else that needed this information inside the empeg (userland apps) I suspect would much rather grab it from /proc than parsing the serial line themselves. I'd say turn it on internally and always strip from the serial unless notify=1 is explicitly in config.ini.

If it truly is a problem, couldn't you add more indirection? Have the player dump to ttyS0 (and internally duplicate to ttyS1) and whatever software that wants to have complete control over the serial output from the player could watch that, while your massaged output could go over ttyS1 & /proc. Or does the serial hack apply to all serial ports? Maybe I'm making this more complicated than it should be. That's what I get for armchair kernel-hacking

I think it would be best if there was an option to choose whether Hijack should output or not regardles of notify=1.

TommyE

Yup. It's broken alright.

I just shoved it out late last night, hoping you'd test it for me.

But now I'm working on it again.. could be a while -- don't have all my fancy tools/hardware here that I'm used to using back at the office.

-ml

>I think it would be best if there was an option to choose
>whether Hijack should output or not regardles of notify=1.

Well, it turns out to be a moot point.

The player seems to use syslog() for its "notify" output, which is a separate kernel path from regular serial port output from an application. This means I can safely ALWAYS have hijack scanning for notifications and updating /proc with them.

But I don't really have an easy way to force the player to "turn them on".

So, to use this feature in the upcoming (fixed) v85 release (in a few hours), one will need to turn on notify in the config.ini file, using the normal [output] notify=1 stuff. But I will add an option to have Hijack supress the serial output of the notify stuff for those who don't want it actually spewing out.

Either way, no interference with "normal" serial port usage from other applications.

Cheers

-ml

I just shoved it out late last night, hoping you'd test it for me.

No prob, brings me back to my days in the ol' test lab here at work. I am really interested in this for my lyrics scroller, though I'm afraid the SLOW graphics libraries I have will prohibit it from being usable just yet.

We have a kernel/IDE expert "on staff" here, now we just need to send a free Empeg to someone who has the expertise to write assembly graphics routines. :)

Hmmm...little quicky problem I have in Info:Track mode.

The screen blanker wasn't doing anything at all, and I figured out that because of the CFB was blinking even as the playlist was finished and nothing else on the screen was moving, it was enough to keep the sensor thinking that there was activity.

So, I changed the sensitivity of the sensor to 95% instead of 100%, and voila..it worked. Only, now the screen will go blank in the middle of songs, where the elapsed time used to keep the "active" state, apparently with between the elapsed time and CFB less than 5% of the screen is active.

Does this make sense? Is there a way to not have it blank out on me when it's playing a song, and still blank out on me when there's nothing playing?

Hey Mark, it looks like the details option for knob press redefinition has vanished? Is there a reason for that and if not can we have it back? I really like being able to get the track details without the remote.

-Mike