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.

Right you are! How is your Raspberry Pi project coming along?

I played around with including the system keyboard a bit yesterday and am not really sure how it can be done reliably. As we know, some keyboards (Swype/SwiftKey) are able to send complete words rather than individual characters. This can be problematic, especially if one makes a mistake and sends 'risk' when they meant to type 'rush'. Swype will send 'risk' to the buffer and then display alternative words, like 'rush'. However, 'risk' will have already been sent down the line. A possible way around this would be to have a text field popup where one could compose a search string and then send it to the player when they were happy with it. At that point, I'm not sure if it would be faster than using the old method. But I'm going to code it up and see how it behaves.

Happy weekend to all.

Yeah, you make good points on the keyboard thing -- perhaps it isn't worth the trouble when the empeg's fuzzy T9 input is so fast to begin with.

All of my non-work development projects stalled over the winter, including my RPi project. I did make some progress since I recorded the demo video, including showing cover art, but there's still a fair amount of work ahead to make it stable enough for daily use. In addition to work stuff and family stuff taking up a lot of time, I ran into a bit of a wall on my attempts to reverse-engineer the CAN messages to provide steering wheel button integration and/or develop some kind of custom control panel. Then it got really cold, and suddenly sitting in my garage in below freezing weather staring at hex dumps didn't seem so appealing.

The good news is that your app fits in perfectly as at least a temporary solution, if not a very nice primary interface. I'd still like to get the steering wheel controls figured out, but in the worst case, I'll have something that works pretty well. I actually thought about developing my own Android remote app at one point but (a) I don't have a lot of love for Java, and (b) my Nexus S's screen was too small to reliably use in the car. Now that I have a Nexus 4 and you've done all the hard work, it seems like it could meet my needs perfectly.

So I ordered one of those 5-in-1 USB network jobs from EBay, but mine doesn't seem to have a WDS option anywhere. It does WPS, but I don't see any options for WDS lazy, bridge, etc. I guess there are different firmware builds depending on who you get the device from, or what random firmware they came with, or whatever. As I expected with a cheap item like this, though there is a firmware upgrade function, I can't seem to find any info online about updated firmware for it.

Still a very neat and useful device, but without WDS, it won't handle my LAN connection needs.

Damn! Here is what the WDS screen looks like on mine. Does the web interface on yours look like this? This one shows version 2.1.2.1...

Yeah, my interface looks totally different.

Did you order yours from the seller you linked to? I could try ordering one from there.

I tried a few more google queries and finally hit something that looks somewhat promising, albeit with links to Chinese download pages with no English README or anything. Since these things seem to be made by a dozen different manufacturers and there seem to be multiple hardware designs, I'm hesitant flash just anything, but I'll try reading through that long-ish thread to see if there's any way to figure out the model number, or if anyone's made progress flashing OpenWRT or anything else onto one of these.

The original ebay link I posted was the one I bought. I also read a bit about them working on some more mainstream firmware (DD-WRT,tomato,etc), but nothing was available yet. Good luck!

The ebay seller is 'mambate', out of New Jersey...

I played around in the car a bit tonight and couldn't get things working. Sadly, my firmware doesn't even have any sort of client/bridge mode. It's got a ton of router functions (content filtering, port forwarding, etc.) but no option to bridge the WAN and LAN interfaces. So I'm stuck with a separate network segment and a WAN gateway, which isn't going to work out.

I could try to load OpenWRT on it, but I wasn't looking for a project within a project, and this was only going to be a temporary solution anyway until I can fully integrate my Raspberry Pi in the car, at which point I'll need a wired LAN with at least 2 ports on it for the RPi and the empeg to communicate.

So at this point, I'll probably just bite the bullet and install the WRT54G in my car again. It's going to be a clunkier install, but at least I get 4 LAN ports, and I know that client, bridge, and WDS all work.

I still think I'll get some use out of the mini router thingie, and even if all it's ever good for is a backup power source for my cell phone, it was worth the $18.

I've got a couple more feature requests for the app after finally using it in my car. (empeg in the car for the first time in 9+ months. Yay!)

1. I'd love an option for a persistent item in the notification bar, so that I can easily access the app by swiping down.

1a. It'd be awesome if the notification item displayed the current track info from /proc/empeg_notify.

1b. And it would be incredibly awesome if the notification item had a few action buttons attached to it -- perhaps the four cardinal direction buttons from the front panel would be a good choice. (I don't think apps can accept long presses of the action buttons, but even short presses would be useful for changing tracks and navigating the empeg menu.)

2. Is there some way you could detect gestures on the remote area and send those out as specific button presses? The obvious candidates are swipes in the cardinal directions corresponding to those buttons on the front panel, but I can imagine all sorts of useful ones. (Gestures like swipes are easier to do when driving than aiming for a specific button on the remote.)

Sorry for my absence! These are good ideas, Tony. I will look into incorporating them in the near future

I did some prototyping this morning.

For some reason, Android only allows a max of 3 buttons in the notification area...not sure why they did this, but I'm not very happy with it. If you were only given 3 buttons, what would you have each of them do?

The rest of the notification stuff is done

As for gesturing, it's easy enough to accomplish on its own, but cannot be combined with the pager view I already have in place (the swiping back and forth between remote and playlists) so I am not sure how it could be implemented. Perhaps a 'car mode' screen...

I've been able to build a custom notification with 4 buttons
It doesn't exactly match the look and feel of latest Android theme, but it works. I'm going to refine it a bit more and then push an update.

Cheers

Very cool!

With respect to gestures, I'd be okay with it switching behavior in car mode, but the same effect could also be achieved with a simple checkbox in the settings to disable the "swipe gestures switch between remote and playlists" behavior. You'd then either need to use some other gesture to switch pages (Android can't detect three finger swipes, can it?) or use tab anchors that can be clicked on to change pages.

Nice solution. I have implemented gestures now on the remote (configurable with a checkbox in Settings).

So now describe all of the gestures you'd like to have
I assume right, left, up, down lines to correspond to the physical buttons on the player, but since the app is now using the full-blown gesture package we can make use of more complicated shapes as well.

Cheers

Oh, wow. You are going to regret asking me for a wish list.

I guess the first question is how precise is the gesture recognition? Can it tell a one finger swipe from two or three? And how complicated are we talking about with the shapes? Is there a doc you can point me to that describes the limitations of the gesture functionality you're using?

Right off the bat, beyond swipes in cardinal directions corresponding to the physical buttons, I think it'd be awesome if it could detect the numbers 0 through 9 and send those through as number presses. Just drawing the number 2 to get "tweak artist" would be amazing, provided it's fuzzy enough to get it right most of the time.

If multi-touch gestures work, I would think maybe single finger for the physical buttons, then maybe two finger up and down for volume up and down, two finger left and right for rewind/fast-forward, etc.

lol! I can't find a nice doc that describes limitations, but we can do multi-touch for sure. One minor issue with single-finger 'up' and 'down' is that they will not work at all when the screen is setup to scroll vertically. Which it needs to be to satisfy multiple device resolutions. I have implemented the physical buttons as a straight swipe to the right or left and then a /\ shape for up and \/ for down. Your numbers idea is great as usual, with the minor issue of drawing the 1. It cannot be a simple straight vertical line (see above), but could be drawn like this:



The rest of the the numbers are easy
The nice thing about gestures in Android is that you I can build numerous different attempts at a gesture and name it the same as previous iterations which increases the fuzziness For example, I could create 10 different gestures of the number 8 to increase the app's likelihood of a match when users swipe an '8'. All of my gestures would be slightly different just by virtue of a dumb finger against a digitizer

I am not sure about vertical multi-touch limitations and there may well be none. So that would be nicely solved before it became a problem.

Tomorrow, I'm getting on a plane and flying to a foreign beach for a week so I'll be back at this at that time. Fiesta!

Cheers

Would it be possible to have it scroll only when you use multiple fingers up/down? If so, what about this:

All single finger gestures used for numbers and maybe other "complex" gestures.

Two finger swipes used for the four physical buttons.

Three finger swipe up/down to scroll, left/right to switch between remote and playlist views.

Maybe pinch zoom gestures for volume up/down?

With this, I think you could do the number 1 as a straight line, and there would be no ambiguity with up/down for scrolling.

Anyway, no matter what, this sounds awesome. Have fun at the beach

At Tony's request, I've decided to release the source for this. I've got no time to maintain it anymore.

https://github.com/suomi35/empeg-remote

Cheers!

Awesome! Thanks!

Is the Play Store version fully up to date with the github release? If so, I'll just buy the binary and save myself some fuss!

Answering my own question: Github has "1.93.72hj", Google Play says "1.86.03hj".

Okay, loaded the binary, entered IP address of a working empeg, and all I ever see is "Empeg is unreachable". What am I missing?

Firewall.. Droidwall, to be specific.

App purchased and now working fine!

Thanks

Now I need a recommendation for another Android App:

Something that works the the "Stream" function of Empeg Remote for Android.

Tried a bunch, thus far nadda.

Hey Mark,

Thanks for the support! I use ServeStream to stream stuff from Empeg. It will occasionally lose the stream, but works most of the time

Cheers

If I recall correctly, the only differences in the GPlay and Github versions have to do with gesture experimentation. tonyc and I were trying to allow a wider range of gestures (2 and 3 fingers, etc) for easier control while driving. I never got it working the way I wanted it to though.

Thanks for the app!

This really could really revitalize the empegs I have around here. No more squinting into a tiny display to navigate playlists -- just do it from the sofa or where ever!

Could be good in the car, too. I can just plug the empeg in and toss it (SSDs) onto the rear seats rather than working out a dash mount for it. I think I still have a tiny D-Link pocket router gizmo to give it wifi connectivity with -- might add a jack to export +5V power for it from the empeg first.

Cheers

Installed, works well enough, and not particularly intrusive.
Thanks for the recommendation!

Cheers
-ml

This feature is not working for me on my G510 - the display is locked into landscape - unless there is a setting somewhere?

So now I just need an easy way to access the empeg via ethernet in the car...

Tiny little "pocket wifi bridge", plugged into the empeg over a short length of cat5. Then Wifi between that and your smartphone.

Had something like that (with an older bridge) at one point to allow me to update the empeg while it was in the car. Just a royal hassle getting the ethernet connector to work so that the empeg can be removed easily.

Yeah, that can be a bit of a fuss at times. I once made up a bunch of precisely milled MDF chunks for the purpose -- they fit tightly inside the car dock and hold an RJ45 plug in exactly the right position. Cut the tab from the plug, of course!

Just had another look around, and they're all gone.

-ml

Might be a good excuse to try out another 3D printer...

At the 2019 Meet near Cambridge, several attendees had not heard of this app. I still use it myself, and strongly recommend it to others.

But it is no longer listed on Google Play. So I have PM'd the author (suomi35) to see what the current status is. Ideally we might work out a scheme for me to just provide it inside the new all-in-one builder_v21 images. We'll see.

Has anyone here built a binary from the gihub source?
I don't know how to go about it, and I already have the paid binary from Google Play for myself. But if we could get one built from github then it would be reasonably legit to redistribute in the builder package.

Thanks.

There looks to be a debug version of the apk in github, if that helps at all ?

https://github.com/suomi35/empeg-remote/tree/master/app/build/outputs/apk

That would be quite cool to have...

I copied both of those to my spare Android handset, and then clicked on each, but neither would work/run: "There was a problem while parsing the package."

EDIT Oh, wait. I screwed up and got HTML instead of the .apk. Will try again..

Okay, after actually getting the correct (2MB) file onto my handset, it installs/runs just fine. I will add the app-empeg.apk to the builder image, renamed to the more obvious empeg-remote-android.apk

Cheers

I hope to get round to doing a root filesystem respin from the builder_v21 image Real Soon Now, so that we can all just install a .upgrade to get the extra features from here without having to reformat our drives.

Done!