I just published an Empeg remote for Android called Empeg Remote

If you have a tablet the app will display the remote on the left side and a playlist navigator on the right. If you have a phone then those two items are swipeable. The Empeg's display is incorporated into the remote view which looks pretty cool. You can also change the lens color which changes the overall theme color of the app. I've been working on it and using it for some time now so thought I should polish it up and offer it to everyone else.
I'm offering it for $4.99...times are tough...

Enjoy and feel free to suggest features, etc.

Cheers

Marvelous! You've got your first customer, or one of your first, anyway.

And you have your first feature request.

On my Nexus S, the remote doesn't fit on screen, and has to be scrolled to get to the Info and Visual buttons. I know I can disable the player display (which I'll eventually do when my Raspberry Pi display project is finished) but until then, can you add an option to shrink the remote to fit the screen size? Perhaps preserving aspect ratio, perhaps not -- either way as long as I don't have to scroll.

Looking further down the road, I'm eventually planning to release the software bits of my remote display project (short video of it in action here). Perhaps you could add support for getting the player display from my display daemon via UDP, instead of via the HTTP interface. This would bump the refresh rate from the current ~1 fps to something north of 20 fps. If that's something you'd be interested in adding, PM me and I'll send you the details of the wire format.

EDIT: Ah, now I see you can adjust the refresh rate, but it's still a bit choppy even if I set it under 100ms. Streaming it via UDP would cut down on the TCP/HTTP overhead, but of course the downside is people have to install something on their empeg. Wonder how hard it would be to add a simple UDP display buffer transmitter to Hijack.

Nice work guys!

Starting to feel some seller's remorse already, I'd love to play around with this.

Excellent!

I'll start working on the remote layout...might make it a configurable option to fill the screen or scroll. I think I'll make the display of the hijack button on the remote configurable as well, since it's not part of the original remote.

A UDP display stream would be very cool and could be another configurable option for those of us who don't mind installing another app on the player (that's more than likely all of us remaining users)
If it could make it into Hijack that would be even better...is that feasible, Mark?

Thank you for the support!

Feature request #2: Take input from the keyboard (built-in, SwiftKey, whatever) and translate it into the correct remote button presses for those letters/numbers in the empeg's search UI.

oooooh! Nice one!

I just pushed an update which should give you all remote buttons onscreen. I also made the extra Hijack button display configurable in Settings (checkbox show/hide). It should show up within the next few hours

As for feature request #2, how do you envision showing the soft keyboard?
I was thinking that I could just show it when the Search button is pressed on the remote, but that doesn't really work well if you want to move through PIN>Year>title, etc. We used to be able to show the softkeys by holding down the Menu button on the phone, but it doesn't work anymore after 4.0 it seems...

I might play with a minimal pull-out tab containing softkeys that could be dragged onscreen when needed and off when not. I'll look into it next week.

Ideas?

Cheers

Yeah, I miss the ability to get a keyboard whenever you wanted one with the menu button. Without that, I guess your idea of showing/hiding the keyboard with some kind of pull-out tab would be a good start.

The harder but perhaps more useful behavior would require detecting whether the search UI is on screen and showing/hiding the keyboard when it makes sense to do so. Hijack screen-scrapes the display to detect whether any player menu is up, but it doesn't know the difference between the playlist menu, the search menu, etc, and doing that kind of screen-scraping remotely from a PNG image would be a bit of a pain.

The search button idea could also work, but it'd have to stay in the keyboard mode on successive search button presses until either OK or Cancel are pressed to perform/cancel the search. This could potentially get out of sync with what's actually on the player, but if you had a way to get that UI menu status from Hijack (I don't see it anywhere in /proc, so you'd probably have to get it from a daemon running on the empeg) you could use that to detect when the menu goes away, hide the keyboard, and go back to showing the keyboard when Search is pressed.

Possibly. How large (bytes) is the display image that gets transmitted? Eg. will it fit into a single packet? (I'm travelling, and nowhere near an empeg to check for myself)

Thanks

The display buffer is 2048 bytes, but half of the bits are unused. Whether it fits into a single packet depends on the minimum MTU between the hosts.

I found using 2048 on my network was unreliable, so I needed to shrink the packets down to 1024 bytes. I could have encoded it to fit into 1024 by using the unused bits in the original display buffer, but I was lazy, and didn't want to tie up any additional resources encoding each frame on the empeg side, so instead I just split it into two 1024 byte UDP packets each representing half of the screen, and set a bit in the first half so that the receiving end doesn't get confused as to which half is which in case of packet loss.

2048 bytes is larger than the normal ethernet limit of 1500 bytes (which must include the packet headers too). If it is transmitted with any kind of compression, then it'll be less than that.

But I suppose a pair of ~1KByte UDP datagrams could be used.

Oh, and note that the buffer I think one ought to be using here is the Hijack version from /proc, rather than the empeg version from /dev/display.

(Topic moved to General forum since it's more of a general "Hey, here's a cool empeg-related app" post.)

Thanks for moving the thread, Tony.

I've starting working on the soft keyboard stuff today. I've also added streaming to the device as an option in the next build, provided you have an appropriate music player that supports m3u (I used a 3rd party app called ServeStream for testing...seemed to work well). Unfortunately, the native Android player doesn't like m3u, or at least m3u with external references

I got my Nexus 4 today, and it looks like the scaling of the remote doesn't take into account the soft button area.

Jason, you may want to check out the new Android Studio development IDE/tool. It will assist with showing how the app appears on several devices to work out issues like the one Tony reported.

https://developer.android.com/sdk/installing/studio.html

It looks like migration from eclipse is pretty easy, though I personally haven't tried it yet to see.

Loading that device up in the emulator right now...soft keys...ughhh

Thanks drakino, I'll look into it. I had to update some Eclipse elements in order to get the Nexus 4 emulator, which seems to have broken Eclipse, yet again. So I may switch over to this new IDE right now

Okay, I just pushed a new build...should be reaching you within the next few hours (v1.80.35hj).

Here is a list of updates:
- Added draggable soft keyboard layer to the remote screen (This feature is meant to coincide with searches and make input entry faster than using the alpha-numeric remote buttons. It can be disabled in Settings)
- Added a streaming option to the playlist context menu (Requires an m3u-compatible player on the device e.g. ServeStream to play content)
- Formatting improvements for devices with soft keys (Nexus 4)
- Added home button to the playlist explorer

Let me know your thoughts on the soft keyboard.

Cheers

Long story...

I recently upgraded from my old junky car with Empeg to an X5 sans Empeg. I could not imagine doing any dash mods to the X5 for the empeg so I got an aftermarket bluetooth/ipod hookup that installs behind the OEM headunit, but I just hate using an ipod in the car. My cars have almost always had an empeg lovingly nestled therein. That's just what I expect to interface with when I get in the car. So...I started thinking about wifi in the car, empeg installed in the back, long cables, etc. I planned to use my Android app as a remote and have the phone associate with the AP when I got in the car. However, if my phone joined the car's network, then I would lose the data signal on the phone unless I had a 3/4G modem sitting on the wifi router as well. And I was not about to shell out an extra monthly data plan just to have remote control capability over my player...plus, I work from home and am not in the car that much.

So...I started toying around with the hotspot functionality of Android and quickly found out I could proxy wlan clients bound for the internet and have access back into the locally created wifi network as well.

I also started looking for some kind of wifi router with an RJ45 port that would work well in the car. I found this. It's otherwise known as an MPR-L8 and perhaps a handful of other names. Anyway, it's quite a remarkable piece of kit and we should probably all have one or two just for fun. It even has a battery that will last for 3hrs. I was able to plug in the Empeg via RJ45 and then get to it via wifi from my phone easily. Next, I tried putting the MPR-L8 into client mode and then getting it to connect to my phone, which was in hotspot mode. Victory! I able to surf the net over 4G on my phone while using the Empeg Remote app to control the player.

This led me to create another simple phone app which listens for the existence of a specific SSID e.g. "The Car Wlan" and, upon detecting it, slip into Hotspot mode. The MPR-L8 will then automatically associate with the phone's hotspot and at that point I've got 3/4G data to/from my phone as normal, but also have visibility back into the local wlan where the player is. voila!
This process takes about 30 sec from ignition.

This little app also keeps pinging the wlan for the existence of the MPR-L8 so that when I turn the car off it kills the hotspot and returns to whatever data mode the phone was in prior.

Tasker can do what your app did very easily. I use it to put my phone into hotspot mode when in the car (which the car PC then sees and uses). I used the detection of the car's bluetooth handsfree to switch over to hotspot mode and back automatically.

Tasker can do a bunch of other stuff too so has additional advantages. Please don't take this as a criticism at all - just wanted to mention Tasker since it's so powerful.

Checking out Tasker now...it is really quite powerful! I am going to test it out tomorrow and perhaps abandon my other method
Thanks for the tip!

My empeg setup in my old car used a Linksys router in the trunk and a long cable run to my empeg dock. In the new car, I can probably replicate that with a much shorter run from the empeg in my glove box to a router under the passenger seat, but one of those tiny wifi routers might make things even easier.

Can you do WDS with one of those little routers? In my old car, I had my empeg connecting to my home wifi network via the in-car router using WDS, which let me use an app on the empeg to initiate an mp3tofid sync to pull down music from my file server. I'd like to get that working in the new car again, but adding the phone connection complicates things, because it sounds like there's no way to enable both phone and empeg connectivity without using hotspot mode, which means the phone's the thing serving the wifi network, which means no WDS capability. Not sure how to square that circle.

BTW, the scaling is indeed fixed on my N4, and the soft keyboard thing is hella nice. Any chance it could use the system's keyboard instead? Being able to do searches with Swiftkey Flow would be amazing.

Indeed, it does WPS (Lazy, Bridge, and Repeater modes).
I think it would work for your setup...you could interface with it in the car using your phone's hotspot and the remote and then drop the phone out and take advantage of WPS when you're at home to connect to the player.

I'm not sure if WPS would interfere with its client mode while you're driving around using hotspot from the phone, but I think it would work fine

Glad the button scaling is sorted!

As for the keyboard, I just wanted to get you something usable quickly.
I am going to work on a more robust method for allowing the system keyboard, which is my preference anyway due to Android's obsession with changing how things work from release to release. The more we rely on their methods the better.

I pushed a minor update today which takes care of the http get process persistently sending requests when the app's display is not set to poll. That one slipped by me initially.
No more unnecessary traffic

I'm looking forward to giving this stuff a go soon-ish.
But do pardon the delay -- getting new wheels here soon, and as with many, the empeg isn't going to fit in the dash. So it could end up in some hidden location with either this or Patrick's "display extender" as the interface.

Cheers (and thanks for doing this!)

No worries at all. I am also thinking I should sniff around for a display extender, though it seems to have been years since the last words of that stuff made it here...anybody know if there are still boards, kits available?

After finally getting around to including the streaming capability yesterday (thanks Tony for giving me new inspiration) I have been enjoying, even LOL'ing to surfing playlists and then just playing them right on my phone. My wife thinks I am too easily amused...perhaps so, but it's still neat

Well, it's a two-way street -- your remote app has given me a lot more motivation to complete my Raspberry Pi display extender project, which was itself inspired by Jon Andrews' Raspberry Pi/LED output project, which I just happened to stumble upon on Youtube one night searching for something else, and now seems to have become a full-on replacement player project. Very cool that all of this new development is happening now.

I guess we should doff our caps to the automobile makers for making it so goddamn hard to integrate empegs into newer cars, right? Otherwise we'd just be enjoying empegs in our dash and not spending hours coding all this cool shit.