Hijack v176: @HOME and @WORK in config.ini

Hijack v176 is out, with these changes/additions:

• Fixed some lowercase dependencies in playlist browsing
  

• Added hijack version number to /proc/version
  

• Added pop-up error message for [hijack] option errors in config.ini
  

• Removed echo-back of [hijack] (and [ir_translate]) options on serial port, except for lines which have errors
  

• New menu item for selecting "Home/Work Location".
  

• Revamped config.ini processing: Hijack intercepts config.ini as it is read by the player on startup, and edits the file in-memory using ;@HOME and ;@WORK directives. If the menu is set for ;@HOME, then lines beginning with ;@HOME will be enabled, otherwise lines beginning with ;@WORK will be enabled. This means the trailing portion of those lines will be passed to the player, and the next existing line (if any) lower in the file with the same setting will be commented out. This allows things like this:

  
           [network]
  
           ;@HOME DHCP=0
  
           ;@WORK DHCP=1
  
           DHCP=0
  
  
  
           [hijack]
  
           ;@WORK kftpd_password=n0H4cKz
  
           ;@WORK khttpd_files=0

  
  The logic for this is clever enough to only do the edit when the player itself is reading config.ini on startup, so this will not affect emptool, emplode, ftp, or http access to config.ini
  

Have Fun!

YAYAY! Thanks Mark. Much appreciated. I'll give the home/work thing a go after lunch. Wow... a weekend from request to implementation. Amazin'.

Hijack v177 is out. The only change from v176 is that the "Home/Work Location" menu setting now sends the user directly to the "Reboot" screen afterward, to enable the new setting.

-ml

I'm wondering about the use of this feature. I don't have any real need for it, but am thinking that it might be helpful to have additional 'choose on boot' and 'none' options. In particular, the choose on boot would allow you to select the mode on bootup (remembering the last mode) in AC mode. if you were to use this every day to select different network modes, wouldn't you have to reboot the player for those changes to be used if you only had the hijack menu to select from?

Correct me if I am mistaken..

This got me thinking.. It would also be nice to have ;@AC and ;@DC modes to turn on/off options while in the car.

>It would also be nice to have ;@AC and ;@DC modes
>to turn on/off options while in the car.

Show me a real-life example of how you will use this.

Cheers

I don't think too many people would like the "choose on boot" delay on player startup.. gets very tedious after a while. So, while this does sound like a nice feature, it (1) chews up another flash bit, and (2) probably won't be used after the first few tries.

Cheers

I guess I don't have any real use (other than turning off khttpd/kftpd, which probably isn't even necessary) as my setup is fairly simple right now. I guess I wouldn't put it in jsut for me.. Perhaps someone else might have a need for it, then it would be a useful addition. It was just a thought.

>I don't think too many people would like the "choose on boot" delay on player startup.. gets very tedious after a while. So, while this does
>sound like a nice feature, it (1) chews up another flash bit, and (2) probably won't be used after the first few tries

I agree that it would be tedius if you reboot multiple times. The reason I was thinking about this, is that if you used this to change from a static IP at home, to a dynamic one at work. If your home network used the same subnet as at work, then having a low numbered static IP at home (say 192.168.0.10) could cause ip conflicts unless you made sure to not plug it in until you've switched modes. Again, it's probably not an elegant solution, but I was thinking it preferable to user-error..

I won't add any bloat here for a boot-time menu for HOME/CAR.

But in v178 I have added ';@AC' and ';@DC' as valid tags (very cheap, codewise).

And also new in v178: by default, kftpd/khttpd will not run in DC/Car mode -- saves us a few pages of memory for added buffering in the bumpy car environment. But if you want them anyway, use this option in config.ini:

[hijack]

dc_servers=1

v178 will be released in a minute or less from now.

Cheers

-ml

Cool.. that works for me.. Thanks for the good work..

Do you already disable the writing of the raw and png images when in DC mode? How about the notify stuff? Curious.

Bruno

No, none of that stuff is disabled.

But none of it actually does anything unless accessed.
For example, the screen captures for .png/.raw, only happen
when the /proc/ entries are read.

Cheers

-ml

But in v178 I have added ';@AC' and ';@DC' as valid tags (very cheap, codewise).

Cool. Do you have any plans to handle a three-way conflict between an @DC, @HOME, and @WORK for the same variable?

Currently, ;@AC and ;@DC get processed first, then ;@HOME and ;@WORK.

I suppose something like this would be useful to some foks:

;@DC DHCP=0

;@AC ;@HOME DHCP=0

;@AC ;@WORK DHCP=1

Currently, that won't work, because Hijack won't process comments after the "@" directive, but I'll enable it in the next release.

-ml

Aha, and then I can remove ReserveCache if in car! Very good! (Which reminded me to modify the script in /etc/preinit.d that starts VNC server to refrain from that in the car environment. Ah, that /proc filesystem is really handy!)

Which reminded me to modify the script in /etc/preinit.d that starts VNC server to refrain from that in the car environment.

How are you doing that in a script? I was thinking of writing a special-purpose app for that, but if it's already done....

Check this thread here for a way to do it via a script. Basicially it's just an if statement catting /proc/empeg_power and grepping it for certain things.

With the latest (internal) beta, I have removed "ReserveCache=" completely, and things appear to still work fine.

-ml

Aw, heck, forgot that /proc is not yet mounted at pre-init time! Do you think it is possible to mount it from the script just like that?

Yeah, but you'd better umount it afterwards.

Everything works even on 12MB MkIIs? Do you mean you don't use ReserveCache, or it is not available any more? (There might be some memory-hungry userland apps...)

Yeah, it's not needed anymore with the upcoming beta.

I test everything on my Mk2 player (12MB, 18GB).

-ml

Oh -- if it doesn't work, let me know and I'll figure out a way to find the information from empeg-preinit and pass it to the script as an argument.

It works it works it works it works HOT DAMN it WORKS! (not that i expected any less)

Thanks a ton Mark. Where's that paypal account of yours again?

Awesome. Now i don't have to bring my USB cable to and from work just to change the IP scheme. ROCK.

I've been out of town for a few days and I'm a little out of the Hijack loop (I had the "ancient" v161 on my player.) So it appears 2-drive Empegs can now use the HTTP server's playlist display thingie and play M3U playlists, etc. Well I tried things out and some playlists work, some don't. I haven't figured out why it is, at first I thought it was a limitation on the size of the playlists, but I couldn't confirm it. Then I thought it was just root playlists that weren't playing right, but some playlists below the root level aren't working either. When the playlists are working, I click "Play" and the IE "downloading" box quickly pops up and disappears, then WinAmp starts playing the playlist. On the ones that don't, no such "downloading" box appears, the throbber in the corner of the browser momentarily throbs, but then stops. There seems to be a lot of disk activity after the HTTP connection has ostensibly closed.

So any idea what's going on? Is something timing out? Is there a known limitation on playlist size that I haven't read about yet? I'm still trying to catch up with all the posts here and the info on the Hijack page, so maybe I'll discover something, but I wanted to know if anyone else had problems with certain playlists and M3U output.

Off to further explore the new Hijack features.

No size limits that I know about.. but retest with v180 and see.. one other chap had tagfiles with embedded '\0' (null) characters, and the pre-v180 parser in Hijack treated those as end-of-file.

-ml

Still no luck for me in v180. Same behavior as described above. I'll try to clear out my IE cache to see if that's part of the problem.

Edit: No luck even after clearing my cache. I'm stumped.

Someone mentioned on the weekend seeing differing behaviour between playlists that had more than just the title field populated, and ones that didn't. I know all mine have both title and source populated (I made a macro to do that for me). I can click on the PLAY link of the player root and all my songs will appear in Winamp (~5925).

You may want to look at your playlist tags to see if there's some such pattern to them.

Bruno

Can someone explain to me how to use this? I have static at home and DHCP at work. Please let me know how to set up the dual boot type thing, so I can select where I am. Thanks.

Someone mentioned on the weekend seeing differing behaviour between playlists that had more than just the title field populated, and ones that didn't.

Hmm well I do populate many of my playlists with other stuff incl. Year and Artist. I don't see any reason why that should cause problems...

Well I just tried it out and I have some playlists that do have other stuff in them and they play fine. So I don't *think* that's it.

Sorry I wasn't clear. The playlists that had the problem (in the other person's post) were ones that DIDN'T have any other fields populated.

Bruno

How to setup Home/Work network swtiching:

1. Read this so you are all setup to edit your config.ini, and make sure you have the newest Hijack installed.

2. Open up emplode, connect, and then Under the "Tools" menu, select "Edit Config.ini", and click "Yes"

3. Find the [Network] section in your config file. You should have something like the following if you've setup a static IP in the past:

[Network]
Gateway=192.168.1.1
Netmask=255.255.255.0
IPAddress=192.168.1.20
DHCP=0

4. DHCP=1 means DHCP is on, DHCP=0 means it's off. duh.

5. add the following just above DHCP=x

;@HOME DHCP=0
;@WORK DHCP=1

or visa-versa if you have DHCP at home and static at work.

My final Network section reads as follows:

[Network]
Gateway=192.168.1.1
Netmask=255.255.255.0
IPAddress=192.168.1.20
;@HOME DHCP=0
;@WORK DHCP=1
DHCP=1

6. Hit Okay, then Sync

7. Hold down the volume knob, go to the "Home/Work Location" selection in the menu, set it, and reboot.

TADA! It works!

Hijack v181 is now available.

The only change from v180 is preliminary support for intercepting/emulating the Tuner/Stalk serial port.

By default, nothing strange should happen with v181.
But if you enable "[hijack] trace_tuner=1" in config.ini,
Hijack will dump out incoming packets from the Tuner/Stalk
serial interface (/dev/ttyS0). Eventually, I'll add button
emulation for these codes, enabling the [ir_translate]
facility to operate on them.

What, no tuner you say? No problem. Here's a way for the
curious to see what the Tuner Display would look like on
your RioCar/Empeg, as if you had a Tuner module installed:

[hijack]

fake_tuner=1

Why bother, you ask? Well.. the Sony Stalk control, which
normally plugs into the Tuner module, has at least one command
not normally available without one: "Visuals-". If we can
fake a tuner, then we can issue that command from [ir_translate]
after first assigning it to another button.. someday soon.

Cheers

-ml

But we're going to make sure to ask the empeg guys to add a new (I suppose unused) code for "visual-" right? For those without a Sony stalk, it makes a lot more sense.

I won't be surprised if one day you put your own player into the kernel.

Bruno

Do the @AC and @DC directives work on the actual [hijack] section of the config.ini? I tried to enter

[hijack]
;AC fake_tuner=1

to fake the tuner in the house, but not mess things up when I'm in the car, where I actually have a tuner. However, Hijack behaved as if the line just wasn't there.

-Aaron

They work anywhere in the config.ini file, but they do have to be spelled correctly (with the @ symbol).

[hijack] 

;@AC fake_tuner=1

-ml

Also note that I believe Hijack will behave correctly with "fake_tuner=1" even if a real tuner is installed: it will silently reset "fake_tuner=0" and continue. Or at least it does it for me.

Yeah, note the time on my post. A long sleepless night makes brain not work so good.


-Aaron

>I won't be surprised if one day you put your own player into the kernel

Good, I wouldn't want to cause a stroke or anything when it happens..

Okay, Hijack v182 is out.

This version just has some internal cleanups, but also:

"Home/Work Location" menu only appears if actually used in config.ini

new config.ini option to prevent Emplode/Emptool/etc.. from connecting to the player:

   [hijack]

   ;@WORK disable_emplode=1

Note that if you fsck up and leave out the ";@WORK" prefix, then you'll have to either FTP or revert to an older kernel to fix config.ini afterwards..

Cheers

-ml

You're a jerk, you know I do have work to do and someone might notice that I'm contiually playing with my new toy and all the awesome new features you're throwing into Hijack...



oh yeah, and thanks for writing an awesome kernel

Hijack v183 is out, to fix a BUG in v182 whereby the "Home/Work Location" menu item did not always show up when required..

Also new, the "NextSrc" virtual button code is now smoother in operation than before, unless you happen to have disabled the Kenwood remote in config.ini..

Cheers

-ml

Been too busy for the last few months to pay much attention to my empeg (other than listening to it) and so have only just started catching up on the changes to Hijack... (Had my parents visiting for a couple of months over Xmas and have been looking for and buying a new house)

With your new work on intercepting the tuner and faking the tuner... can you detect the existence of a real tuner before the player software starts...? I am currently detecting it from a user space program and then calling an ioctl to change flags in the kernel but it would be great to be able to detect it earlier from within the kernel before init is called.

Would it be possible to move the code I am currently using into the kernel to try and talk to the tuner to test whether it is there...?

Cheers

Kim

Do you really need to know BEFORE the player starts up?
If so, I can just have Hijack do the same detection sequence that the player uses, just earlier on. But if you can wait until after the player is running, I'll just pick it off from there. Either way, I can make it available in /proc

-ml

Do you really need to know BEFORE the player starts up?

Yep... as I check for the presence of a tuner to determine whether the empeg is in the car or running from mains power (my empeg's power socket is faulty and believes it is always on mains power)

I need to detect this before the player starts so I can override the power setting and make the player believe it is in the car and not blast my ears out with the wrong volume setting.

A useful extension might be to pull out the tuner ID and allow ;@ID1, ;@ID2 conditionals in your config.ini processing so those with multiple tuners/locations could run different things depending on where the empeg finds itself.

As for it being needed in /proc, the ID could be useful... but I would probably just use the value within the kernel to override the power state...

What would be excellent for me would be:

[hijack]
;@ID1 force_dc=1

Or something like that... Hope that makes sense..

Maybe at some point I will get the courage up to take to the empeg with a soldering iron and won't have this issue any more...

Cheers,

Kim