I've remained committed to the gluqlo clock for months now, running it all day and night on the zipit as my replacement alarm clock radio. So maybe it's about time I integrated more stuff. Like the music. That's already pretty decent. I can use the alt-home key combo to return to the gmenu2x screen and pull up an internet radio stream in the ziptuner. Then maybe set a sleeptimer and alt-arrow back to the clock screen. The default ebindkeys OnPlay and OnStop scripts provide rudimentary controls via the Play and Stop buttons, even when the clock app is on-screen. Same for the side mounted volume control buttons. Nice, but there's always something more...
I only have a 2GB bleeding edge Openwrt SD card in the alarm clock zipit. So no space has been available for any music from my personal stash that I meticulously converted from my super awesome record collection. And that got me thinking... Plenty of people have hooked up their zipits to network media players in the past. Maybe it was high time for me to do the same. With that in mind, I launched the python simpleHTTPserver in the music folder on my laptop, and it worked well enough to play some music via wifi on my chromebook. That's a good sign. So I whipped up a script to auto generate album playlists for every folder in the entire music directory tree. Sadly, I found less success with that on the chromebook than I expected. No can do the playlists? Oh well. The zipit's my real target anyhow. And it seems mplayer on the zipit can make use of the wifi playlists.
There's issues though -- mplayer runs out of memory on large ogg files, and I need to check if it can handle any of the large mp3 or flac files in the collection. Meanwhile gmu 0.10.1 supports streaming for mp3s and opus, and new source code is available to extend that to the other codecs. So I tested gmu on a few large mp3s, and it works, but has some limitations. Mplayer can fetch and use remote .pls files with relative web paths, and it allows spaces in the URLs. Gmu needs a local .pls file with absolute web paths containing %20 instead of spaces in the URLs. Not a big deal, but then the marquee scroller up top shows the %20 substitutions instead of spaces, which is a bit ugly. It'd be nice if gmu did the %20 substitution for me, or perhaps displayed the TITLE tag in the scroller instead of the URL.
Must tweak my playlist creator script to cut the track numbers from the TITLE tags.
Also gmu fails to
refresh most bits on return from other ttys via ALT-arrows. Actually, only the top blue bar with the scrolling status got redrawn. I got some more to display by cycling through the playlist with the up and down arrow keys. I’m
not sure if it gets an SDL refresh event or somesuch, but it’d be
nice if there was some way to trigger a full screen redraw. Otherwise I
normally prefer to keep the stingy redraws, limited to things that are actually
changing on-screen in order to maintain the lowest possible cpu usage. Which reminds me, I still need to dig into the gluqlo code and put it's screen refresh routines on a diet.
If you read between the lines you can see the gmu log messages bleeding thru.
The final piece of this puzzle was the front end. For a while I considered hacking the ziptuner, but it turns out the links browser works adequately for searching on the web server for album playlists. You can config it to launch an audio player either in the foreground or background. But I chose to simply save a playlist in a convenient location and quit links before starting the audio, to conserve memory for the playback task.
I wonder if the node server has an option to skip the file permissions on the left.
In my opinion the node.js simple http-server seems a bit smoother than the python one, so I settled on that for now. It passes a unique pls+xml mime ID for playlists that I was able to capitalize on with a new association in the ~/.links/links.cfg file.
association "music playlist" "application/pls+xml" "getpls %" 21 1
To pull all of this together I created some new glue scripts in /usr/local/bin, and tweaked the existing onPlay and onStop scripts. And then added some new Find and Play gmenu2x apps to work together with the glue scripts and flesh it all out. Still need to dig up some new icons. I'm thinking maybe some jukebox icons -- one focused on the jukebox menu for Find, and one with musical notes coming out for Play. I'm sure the internet already has something like that.
I got pretty lazy with the icons...
For the new scripts I simplified things by always saving the fetched playlist as /tmp/__album.pls and then keeping a permanent __album.pls softlink in the gmu directory that points to the one in /tmp. There's more work to do, but eventually I should have some new zipit goodies to share here...
If only the file browser tab could browse for playlist files from the webserver on my laptop then my work here would be done, I think...
Turns out the clock app was an easy fix. Simply replace SDL_WaitEvent with an SDL_PollEvent call and include a quarter second SDL_Delay when no event is available. Runs at less than 1% cpu now, as expected. The SDL wait and the SDL timer functions appear to be busy loops of some sort on the zipit. Same for the pthread cond_wait functions. Must be something odd in the musl libc implementation we're using. Maybe an openwrt musl update would help?
Anyhow, that let the music play, even with gmu running in the background behind the clock. However gmu still needed work as it was hogging over 70% of the cpu. I got it down to 60% by eliminating the SDL timer init whenever I excluded the sdl frontend with a -p frontends/gmuhttp.so command line option. Then I realized I could save another 10% by eliminating all frontends with a -p dummy option.
But all that effort left me with no interface to control it with. Until I realized the code was already handling the SIGINT and SIGTERM signals as a way to do a clean shutdown. So I expanded that to include SIGSTOP, SIGUSR1, and SIGUSR2 to provide basic pause, prev, and next functionality via signals sent by the killall command. Then I created a half dozen simple scripts in /usr/local/bin and recycled the media app buttons from IZ2S to run them. Looks pretty functional...
After a round of testing I realized I sorely missed the "now playing" screens from the web and gmuc frontend interfaces that I'd eliminated in the lean and mean setup. So I added a handler for the unused SIGSYS signal to dump some now playing text to a file in /tmp.
It's simple, but it works.
I also found a convenient spot in the code to fix all the %20 text in the "now playing" song title from the web playlists. You can see the result on the PLAYING line of the gmuinfo text above, and also in the marquee scroller on the SDL GUI. Yes, you can actually read it now. I also tweaked the code to skip the current song and playlist autosave options whenever a playlist is passed on the command line. That makes so much more sense for my purposes. To add the finishing touch I gave the gmuinfo script a ziptuner msgbox dialog style makeover, because I like it, and it was easy -- only 3 more lines of script code.
I think I'm getting to the point where some goodies should be made available. So expect something of that nature shortly...
I also made a pre-release executable tarball just in case anyone is desperate to try it.
And I stashed a substitute playlist fetcher script in my scriptuner repo. It's a bit nicer than repurposing the links browser for that job.