Suggestion: LMS handling attributes of Programme as well as Song

[Paul Webster]

When streaming from radio sources it is possible, via existing plugins to retrieve information about the programme that is currently playing (or even being listened to via a catchup service).
Currently those details are squeezed into song information (some combination of artist, title, cover, album, duration) meaning that the information is not readily able to be presented when a song is playing (assuming track details are captured by the plugin).
On old SB devices there is not really enough space to show a lot of info - but on Touch and modern home-built stuff, plus web interfaces there is room to present a lot more.

So - my suggestion is that LMS should accept a few more attributes (eg progtitle, progdescription, progicon, progstarttime, progduration) then a display handling module would allow the user more control over what is shown.
e.g. Touch-style display could show the programme name and small icon up in the top left of the screen (even with a 2nd progress bar) when a named song is playing.

I know that this would mean a lot of places would need to be checked (potentially everywhere that uses "artist"/"title") - but my guess is that most places could ignore it.

[mherger]

> Currently those details are squeezed into song information (some
> combination of artist, title, cover, album, duration) meaning that the
> information is not readily able to be presented when a song is playing
> (assuming track details are captured by the plugin).

If the metadata provider can distinguish between artist and title etc.
then that information would very well be displayed in appropriate
places. The problem is for many radio stations that such information is
not available, but there's only a single string of information with no
hint about what it is.

--

Michael

[Paul Webster]

True - but there are plugins today that provide both Programme and Song information - and they have to push it into the song info.
For example BBC iPlayer, and my Radio France, ABC Australia, KCRW and CBC Canada (each of which handle multiple stations) all collect programme and song info.

[mherger]

> True - but there are plugins today that provide both Programme and Song
> information - and they have to push it into the song info.

I fear I don't really understand what you're looking for... can you
illustrate with some screenshots or something?

--

Michael

[Paul Webster]

Will do - Tapatalk having problems with image upload at the moment but I have grabbed screenshots while playing ICI Musique Montreal (using CBC Radio-Canada Francais plugin).

Here is a programme playing before I had the track details



Here it is a bit later with track info (replacing the programme info)



and here is the track playing on JiveLite



and my suggestion is that when the track info is shown we could also (optionally by user choice) show programme name, progress bar and small icon up at the top.

[Paul Webster]

Also - TuneIn sometimes has programme information ( https://help.tunein.com/how-do-i-upd...ule--SkIFQfiuG ) .. which LMS has access to.

I do not know how many broadcasters provide that programme data to TuneIn and keep it up to date.

This has a duration and seconds_remaining field - so a progress bar could be shown.

Currently LMS is able to show programme names from TuneIn because it takes the first two name fields and drops them into artist and title.
But TuneIn actually indicates what the item is with the "key" field.
So LMS could store them separately from the real artist/title

{
               guide_id  => "s112653",
               image     => "http://cdn-radiotime-logos.tunein.com/s112653q.png",
               items     => [],
               key       => "station",
               name      => "Radio Melody 105.7",
               preset_id => "s112653",
               type      => "text",
               url       => undef,
               value     => "Radio Melody 105.7",
             },
             {
               duration => 7200,
               guide_id => "p1000896",
               items => [],
               key => "show",
               name => "Radio Melody am Vormittag",
               seconds_remaining => 2815,
               type => "text",
               url => undef,
               value => "Radio Melody am Vormittag",
             },

Some supplementary reasons - none of which are big issues.
Having real programme fields would also prevent wasted lookups of artist info in MAI (although it is not likely that an end-user would click on artist info when the radio station is not showing song info ... but the display might be left open).
For those users who have scrobbling of internet radio listening enabled ... it would help to stop (unless a new option was added to allow it) station/programme details being scrobbled. (e.g. like this ... https://www.last.fm/music/Nachrichten )

[Paul Webster]

World's worst mockup of how it could look (with each element being enabled or not by the user)

[bpa]

I agree with the first post - that additional information should be available in identifiable files and it is up to UI how to present the data whether on "Now Playing" screens and/or through More - rather than plugin through getMetatdataFor routine merging data to fit into 3 standard fields but which is different for each plugin.

I think the fields available to depend on the source. I think there are a number of sources and if this sort of change is going to happen, we should have a scheme that covers
- files - artist , album, track, - classical often poses additional problems but I don't want to solve that here
- Podcasts - source, date, title, episode, descr
- streaming services like Spotify, Qobuz - artist , album, track - I'm not a user so others can add but maybe also "playlist" or channel (what is displayed with a user with a playlist of mix local and streaming tracks ?)
- Radio stations - on demand - program name/episode , program contents, Brand/Series, Station name
- Radio stations - Live - current track/segment, program , short description, station name - other possibly time left and next program.

For Radio there are some users who want long descriptions and others who want short especially for Classical broadcast where description can be very long

Since these are the items that comes to mind, they are a bit chaotic but I think it means the that an overarching "tag" is needed to indicate the "source" so that the UI can choose a layout and know what fields should be available and what they means.

In implementation terms - we can go for a big change in many places or crowbar it into an existing field (e.g. if "description" is a string - then process as currently, if "description" is a hash - break out the fields in the UI)

[mherger]

Ok, got it now. As bpa outlined, this might be a major project. The
schema we use to store data with tracks would need to be enhanced. But I
guess that would be just the smallest part of the work. Collecting the
data from the numerous sources and putting them into meaningful
categories might be the next big challenge.

And then there's the UI work. UIs for which there hasn't been any
development in years. UIs which come each with their own set of
constraints (size, ability to show artwork, width, height...)

And that doesn't even cover the endless discussions about the "right"
way to do all of this :-).

TBH. I'm mostly driven by my own needs and interests. And I mostly see a
lot of work here, and little in it for myself (except the challenge to
do it right). A challenge this size would need support by more people
than just me. But I'm happy to help where I can.

--

Michael

[bpa]

Ok, got it now. As bpa outlined, this might be a major project. The
schema we use to store data with tracks would need to be enhanced.

I think this change relates to streamed services and as such the data is ephemeral (i.e. some or all fields can change while stream is playing) and probably does not have to be stored in a schema but could be something "lightweight" like thge playing song's plugindata.