Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Make it possible to maintain upmpdcli-radio.conf via Moode’s interface
#1
I mainly use as a UPnP renderer c/o Upmpdcli.  One of Upmpdcli’s features that particularly appeals to me is its ability to stream internet radios, but this is dependent on editing and maintaining ‘upmpdcli-radio.conf’, where the appropriate urls etc. reside.  While by no means is this a substantial burden, but Upmpdcli’s radio stations are currently completely freestanding from Moode’s own very good system and the actual process of editing ‘upmpdcli-radio.conf’ is typically done via ssh and requires halting and restarting the Upmpdcli service, which isn’t quick or ideal.

I would therefore love to see this process of editing and maintaining ‘upmpdcli-radio.conf’ incorporated into Moode’s own radio listing, as available via its interface.

As an idea, if a user had set up Moode to act as a UPnP renderer, and had selected a radio station that featured in Moode’s radio listing but wasn’t included in ‘upmpdcli-radio.conf’, an ‘add radio to UPnP’ option would be available by right clicking the mouse.  If this option was chosen, ‘upmpdcli-radio.conf’ would automatically be modified behind the scenes, by appending the appropriate radio station and by also adding the ArtUrl line, so that Upmpdcli will be able to use the same radio station artwork/logo as Moode.   Similarly, if the selected radio station was already included in ‘upmpdcli-radio.conf’ a ‘remove radio from UPnP’ would be available instead, and if this was chosen the appropriate references to that radio station would be removed from ‘upmpdcli-radio.conf’.
Reply
#2
@Zigzag


Would it suffice to have a script in moOde which synchronizes the upmpdcli.conf entries with the contents of moOde's Radio directory?

It seems to me this approach would involved less fiddling with the UI-related code and less clicking on the part of the user. 

Just idly musing while waiting for my coffee to finish brewing. Smile

Regards,
Kent
Reply
#3
Thanks for coming back to me TheOldPresbyope. Yup, your alternative of having a script that synchronizes the entries of upmpdcli.conf with the contents of moOde's Radio directory would more than suffice. My suggestion was OTT - I hope this idea of having a script instead is much easier to implement.
Reply
#4
(12-05-2018, 10:44 AM)Zigzag Wrote: Thanks for coming back to me TheOldPresbyope.  Yup, your alternative of having a script that synchronizes the entries of upmpdcli.conf with the contents  of moOde's Radio directory would more than suffice.  My suggestion was OTT - I hope this idea of having a script instead is much easier to implement.

So I took advantage of some downtime yesterday to explore possibilities for a script. 

1. Getting basic station info from the .pls files in moOde's RADIO directory into upmpdcli-radio.conf (referenced by upmpdcli.conf in moOde) is reasonably trivial. 

Attached is a zip file of the 184 upmpdcli-radio.conf entries---station name and stream URL---I generated for the stations which are in the upcoming r4.4 RADIO directory. I imagine it would be straightforward for Tim to generate the same entries once he has the RADIO directory locked up in the late stages of preparing a moOde image.

You could either append these entries to your existing /etc/upmpdcli-radio.conf or replace it with them. Caveat: I did not try to validate the stream URLs. 

2. Getting station-artwork references into upmpdcli-radio.conf is harder. 

In moOde, the logos you see are stored in the local filesystem (IIRC, moOde has code to make use of  any remote links stored in its sqlite3 database but I see none in use at the moment).  Since upmpdcli requires a URL to pass to UPnP Control Points ("artUrl=" in the station entry), I referenced the nginx server already running in moOde to serve these logo files. This mostly works but there are two issues: 
  • necessarily, the stored URL contains the "protocol source", either hostname or IP address. This can be a problem because both are subject to change at any time after moOde has been installed on an RPi. Entries in upmpdcli-radio.conf would have to be adjusted each time this happened.
  • the local logo-filenames include characters like spaces, ampersands, and apostrophes which are "unsafe" in URLs. I've been stumped here. I have only two apps which can access moOde's UPnP radio directory, BubbleDS on my android phone and Linn Kazoo on my iPad. In limited experiments, I haven't found a method of encoding the URLs in such a way that both apps will display the logos; I've been able to please one or the other but not both at once. I need to look at the UPnP specs to figure out what is the "correct" encoding rather than try to infer it from the behavior of undocumented apps.
I haven't addressed the possibility of generating entries in upmpdcli-radio.conf from a named moOde playlist of radio stations. That could be a way to pare down those 184 stations to just the stations of interest. Neither have I addressed ongoing maintenance---adding/editing/deleting stations. 

And of course the sky's the limit if one starts with a clean sheet of paper but that's not going to happen.

Regards,
Kent

PS - this is for the version 1.2.x upmpdcli we are using. The newer v1.3.x has additional functionality including some scripting capabilities for radio entries which might be useful once we move to it. Still looks a bit experimental though.

PPS - before someone feels the necessity to pipe up, yes, I know there are APIs to fetch station artwork, indeed complete station info, from resources like Dirble (commercial) or Radio Browser (free) but they don't fit into the current framework. Maybe someday.


Attached Files
.zip   upmpdcli-radio.zip (Size: 4.26 KB / Downloads: 4)
Reply
#5
Ok, so I resolved my logo-filename issue. Logos now display in both Bubble DS and Linn Kazoo, which are the only suitable apps I have.

Below is a Python 3 script (won't work in Python 2.7 without a mod) which reads all the .pls files in the moOde RADIO directory and prints its output to the command line. This output can be redirected to a file which can replace or be concatenated with /etc/upmpdcli-radio.conf.

Put it in pi's home directory on your moOde player; read the limitations in the comments; and assuming you've made it executable invoke it either as

Code:
./gen-upmpdcli-radio.py

to see its output, or as something like

Code:
./gen-upmpdcli-radio.py > upmpdcli-radio.conf

to save the output to a file. If you choose not to make it executable, then invoke as "Python3 gen-upmpdcli-radio.py ...."

This script does not directly overwrite /etc/upmpdcli-radio.conf on purpose but if you are adventuresome, you could do so by invoking it as root and redirecting to that file.

Regards,
Kent

gen-upmpdcli-radio.py
Code:
#!/usr/bin/python3
# utility script to read the .pls files in the moOde r4.4 RADIO directory
# and create counterpart upmpdcli-radio.conf entries, complete with
# artUrl links to the station-logo thumbnails

# prints output to command line; output can be redirected to a file
#    which can replace or be concatenated with /etc/upmpdcli-radio.conf

# Limitations:
#   - the artUrl references a specific moOde player by hostname.
#       - UPnP apps accessing this player must be able to resolve this hostname
#       - If the hostname changes, all artUrl entries must be changed
#   - ignores multiple entries in a .pls file
#   - takes station name from the .pls file name and ignores Title lines in
#     the .pls file, many are too long to be of use; some differ in subtle ways
#   - assumes station logos are in .jpg format which is currently true; could be
#     modified to test for the actual logo file format, e.g., jpg, png, etc.
#   - uses thumbnails rather than full logo art. This may be a limitation
#     to some, a feature to others --- thumbnails look good in a directory listing,
#     not so good in full screen. LOGO_DIR_rel could always be changed.
#

import os, urllib.parse

# maybe overly cautious, but don't assume there
# is no whitespace in .pls entries
def getURLfromPLS(dir, basename):
 with open(dir + basename, "r") as file:
   for line in file:
     if "File1=" in line:
       return (line.replace("File1=", "").strip())
       break
   close(file)

# some useful strings based on moOde r4.x directory structure
# later code assumes there are no unsafe characters in these strings
RADIO_DIR="/var/lib/mpd/music/RADIO/"
LOGO_DIR_rel="images/radio-logos/thumbs/"
LOGO_DIR_abs="/var/www/" + LOGO_DIR_rel

# use current hostname for http protocol source
HOST=os.uname()[1]
URLfrag="http://" + HOST + "/" + LOGO_DIR_rel

# create entries suitable for upmpdcli
ListOfFiles=os.listdir(RADIO_DIR)
ListOfFiles.sort(key=str.lower)
for entry in ListOfFiles:
 if entry.endswith(".pls"):
   radio=entry[:-4]
   url=getURLfromPLS(RADIO_DIR, entry)
   safe_logo_ref=urllib.parse.quote(radio + ".jpg")
   artUrl=(URLfrag + safe_logo_ref)
   print("[radio " + radio + "]")
   print("url = " + url)
   print("artUrl = " + artUrl)
   print()
Reply
#6
Sorry TheOldPresbyope I've been away for a while - many thanks your script
Reply
#7
Hi everybody,

I've tried the python script, but for some reasons, it does not work with all radio streams...

So, I made my own in a bash / awk script that I share with you.

#!/bin/bash
pls_source=/var/lib/mpd/music/RADIO/*.pls

SUDO=''
if (( $EUID != 0 ))
then
SUDO='sudo'
fi

replicate_radio()
{
upmpd_conf=/etc/upmpdcli-radio.conf
mv $upmpd_conf $upmpd_conf.old
awk -F= '/File1=/ {url=$2;"hostname" | getline hostname;n=split(FILENAME,current_file,"/");split(current_file[n],file_no_ext,".pls");gsub(/\ /,"%20", file_no_ext[1])}\
/Title/ {print "[radio " $2 "]\nurl = "url "\nartUrl = http://" hostname ".local/images/radio-logos/thumbs/" file_no_ext[1] ".jpg\n"}' "$@" >>$upmpd_conf
systemctl restart upmpdcli.service
}

FUNC=$(declare -f replicate_radio)
$SUDO bash -c "$FUNC; replicate_radio $pls_source"


AWK is so powerful !! ;-)
Reply
#8
@"clemarc@gmail.com"

Thanks for your contribution. My one-shot solution was written a year ago---moOde was v4.3 or so---and I would not be surprised if more than one detail has changed since. 

Regards,
Kent
Reply


Forum Jump: