gijstimmers / yamlradio Goto Github PK

For instance in ~/.config/yamlradio/history.log. The lines should be lead by the date and time of display if possible.

You might want to consider handling ICY meta data yourself, instead of getting them from the stdout of mplayer. Advantages include:

• more control over the finer grained ICY meta data: as far as I can tell, the data is now matched with a regex on the output of mplayer, whereas the raw ICY data seems to be broad casted with some kind of predefined structure.
• more meta data: mplayer only displays the stream title. There seems to be other interesting meta data (e.g. icy-name, icy-genre, icy-description, ...)
• independence from mplayer: imagine you want to plug in another media player back-end some day...

This link explains how the SHOUTcast protocol broadcasts the ICY messages and this link provides a rather low-level proof-of-concept python program.

Interestingly, this project provides a python library that does the job. I modified the example program of their README a bit:

from streamscrobbler import streamscrobbler
streamscrobbler = streamscrobbler()

streamurl = "http://mp3.streampower.be/radio1-high"
stationinfo = streamscrobbler.getServerInfo(streamurl)

print "the stationinfo is: ", stationinfo

##metadata is the bitrate and current song
metadata = stationinfo.get("metadata")

print "the metadata is: ", metadata

## status is the integer to tell if the server is up or down, 0 means down, 1 up, 2 means up but also got metadata.
status = stationinfo.get("status")

print "the status is:", status

feature request: instead of overwriting the ICY info on update, display and update the previous as well as the current info

Radio1 for example typically alternates the streamtitle with name of the current song with the name of the radio show. This implies the name of the current song is periodically invisible...

wanted:

Speelt nu af: [Radio 1 (België)]
Info:         [Monschau]                                                        
Info:         [ARTIST - song]

Some thoughts on how ICY messages are currently processed and displayed:

ICY Considerations

1. The Shoutcast/ICY protocol seems to be the de facto standard for meta data in online radio streams
2. This protocol sucks in many ways:
   • proprietary: there seems to be no official documentation. This page describes ICY internals a bit, as found out by reverse engineering..
   • the meta data is interweaved in the audio stream and only shows up at regular intervals
   • there is only a single field StreamTitle to hold all the most relevant info: current song's title and current song's artist and name of the current radio program
3. As a result, ICY messages are inherently station-specific:
   • the value of the StreamTitle field is typically alternated with (i) radio program info and (ii) current song's artist and title
   • the current song's artist and title are formatted at will (e.g. dash-separated, capitalized, ...)

Software Requirements

IMO, yamlradio should:

1. exploit station-specific behavior by allowing users to plug in code that "knows what to expect from a station" (as you proposed in issue #3 ), while at the same time clearly separating these code stubs from the rest of the code base.
2. allow a pluggable visualization scheme for everyone's needs (cf. kotnetcli): some users want the song title to be colored bold, whereas others want an OS-specific notification, ...
3. remain relatively lightweight by default, yet extensible as needed

Current Situation

The station-specific communicators from issue #3 meet criterion (1) above, but fail criterion (2). They encapsulate station-specific behavior, while at the same time enforcing one specific layout (e.g. non-colored and non-capitalized plaintext on the stdout of a 80-char-wide terminal).

Proposed Solution

We need to separate station-specific ICY handling from common visualization concerns. On every arrival of ICY meta data, yamlradio should:

1. pass the StreamTitle field to a station-specific parser (if any). This parser "knows what to expect from its station" and thus returns:
   • an indicator for the type of the meta data (e.g. "current song info" or "radio program info")
   • finer-grained info, dependent on the meta data type (e.g. split the "current song info" into the artist and song title)
2. pass the fine-grained info (if any) to a pluggable communicator interface that handles the visualization as desired (cf. kotnetcli). If no custom parser was found in step (1) above, pass the raw ICY data via a dedicated method.

Other fixed ICY meta data such as icy-name, icy-genre and icy-description (cf. issue #14 ) are updated when switching a radio station through a corresponding communicator method.

The communicator interface might thus look like:

• displaySongInfo(artist, title)
• displayRadioShowInfo(title)
• displayRawICYStreamTitle(streamTitle)
• displayRadioInfo(icy-name, icy-genre, icy-description)

Final Thoughts

I think the above will improve end-user's experience, since a real added value over plain mplayer will be created. IMO, it won't blow up the code base too much (3th criterion above), since the existing station-specific communicator scheme can be transformed into a station-specific parser scheme.

Looks like the current stream url is not used anymore

Current layout:

r1nl:
  naam: Radio 1 (Nederland)
  url:  http://icecast.omroep.nl/radio1-bb-mp3
r2nl:
  naam: Radio 2 (Nederland)
  url : http://icecast.omroep.nl/radio2-bb-mp3

(...)

It's a bit strange to put the channel abbreviation at a higher level than the name and URL. We need a data container that keeps the appropriate data (abbreviation, name, url) together in a set-like format. Something like this would be nice:

afk: r1nl
naam: Radio 1 (Nederland)
url:  http://icecast.omroep.nl/radio1-bb-mp3

afk: r2nl
naam: Radio 2 (Nederland)
url : http://icecast.omroep.nl/radio2-bb-mp3

(...)

At the moment, when playing yamlradio, the audiostream is downloaded twice: the first one to keep the ICY information up-to-date, the second one to play audio.

This is not really elegant and may even cause problems for users with bandwidth limits.

Some solutions I can come up with:

1. in icyparser, save the audio bytes to a temporary local mp3 file.
   • The problem with this solution is that this audio file may become way too big if the user keeps yamlradio running for a long time. I don't know of a way to trim the first bytes while playing to keep the file short and yet still guarantee reliable playback.
2. in icyparser, create a socket server (?) and serve the audio bytes there in real-time. Hook yamlradio in to this byte stream instead.
   • The main problem with this solution is that it's just hard to implement. I have to learn how to set one up, and pass the file-object or a reference to the server reliably to yamlradio. Also, the bytes sent to the socket server need to be brand new - in other words, if, for instance, mplayer takes a while to start, I still want the newest bytes to be played and not the music that was on radio a minute ago. Yet, a little bit of buffering would be acceptable.
3. ditch mplayer and use a native Python solution to play a bytearray.
   • IMO this is the least favorable solution. I like mplayer, it's reliable and robust with lots of features, and I have no plans to reinvent the wheel. Also, playing a bytearray is likely harder than it sounds.

This would be interesting.

Proof-of-concept code:

import sys
import time
sys.stdout.write("\x1b]2;Hot Chip - Need You Now\x07")
sys.stdout.flush()
time.sleep(2)
sys.stdout.write("\x1b]2;Monschau\x07")
sys.stdout.flush()
time.sleep(2)
sys.stdout.write("\x1b]2;Hot Chip - Need You Now\x07")
sys.stdout.flush()

radio.py is set to return to the first character of the line when displaying a new ICY message. In the current situation, ICY messages longer than 65 characters may appear, which leads to the ICY message being displayed on two lines. When a new ICY message appears, the first line being cut off, with the new ICY message on a new line. IMO, this is undesirable behaviour.

Proposal: cut off the ICY message when longer than 65 tokens to prevent this.

• Connection lost
• Subprocess killed externally

Stopping gives the following error:

Speelt nu af: [Radio Scorpio]
Info:         [082 Georgia - Petwo, Reality Souf Broker]Traceback (most recent call last):
  File "/usr/local/bin/yamlradio", line 11, in <module>
    load_entry_point('yamlradio==2.2.1', 'console_scripts', 'yamlradio')()
  File "/usr/local/lib/python3.5/dist-packages/yamlradio/yamlradio.py", line 67, in main
    rd.stoppen()
  File "/usr/local/lib/python3.5/dist-packages/yamlradio/radio.py", line 57, in stoppen
    self.stream.stdin.flush()
BrokenPipeError: [Errno 32] Broken pipe

Some radio stations are pretty consistent in the way they transmit ICY info. It would be cool if artist/title information could be shown via native desktop notifications. As I see it, the most logical choice for this would be to pass ICY information to the MPRIS protocol.

Some radio stations put everything in the ICY information, so we need a smart, custom mechanism that figures out if information really needs to be shown.

This has been an issue at least since yesterday.

$ rd r6nljz
Speelt nu af: [Radio 6 Jazz (Nederland)]
Kan niet afspelen: stream offline

• 9 - 0
• - - =
• Mute - Unmute with m

radio.py is best used as a standalone program. Therefore, I changed the directory structure so that we can create a PyPI package from it, later on. See 110414b.

We need to provide a good executable name. Some suggestions:

• radio: probably the most obvious one. Easy to remember.
• rd: shorter, which is neat when you have to type out the channel name as well
• ...

What do you prefer? Note that you can always create an alias to suit your needs, this is just about default behaviour.

• use flag to disable video output
• make icyparser disregard non-ICY streams

see title; in communicators/default.py

At the moment, there may be several reasons on why stream cannot be played:

• mplayer2 is not installed
• the stream is offline

These are currently being handled by Radio().afspelen(). I don't really like this.

Solution: create a separate class with modules that check whether everything is in place, e.g.

class CheckSetup():
    def stream():
        if stream_is_online:
            STREAM_ONLINE = True

    def mplayer(self):
        if mplayer_works:
            MPLAYER_WORKS = True
    def check(self)
        return(self.stream(), self.mplayer())

if not False in CheckSetup():
    continue