Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ShoutCAST DNAS rejecting title updates #311

Closed
expert-geeks opened this issue Sep 28, 2017 · 10 comments
Closed

ShoutCAST DNAS rejecting title updates #311

expert-geeks opened this issue Sep 28, 2017 · 10 comments

Comments

@expert-geeks
Copy link
Contributor

expert-geeks commented Sep 28, 2017

Libretime version: Current pull from git repo 29e7cc3
Ubuntu 16.04
ShoutCAST DNAS 2.5.5.732

I'm trying to connect to ShoutCAST DNAS and while the audio connects fine, the ID3 data is discarded. By checking the logs after a chance forum remark, it seems that ShoutCAST is ignoring title updates generated by libretime. ShoutCAST DNAS apparently doesn't like titles that 1) start with punctuation or special characters, or 2) multiples of special characters in the title and stops DNAS updating the title.

When connecting, DNAS accepts the initial offline title (excepts taken from sc_serv.log);
Title update [LibreTime - offline]
but then rejects the track data, leaving the 'Libretime - offline message', in the DNAS ID3 cache.

When 'Stream Label: Artist - Title' is selected, Libretime generates the titles with a leading dash, and then ShoutCAST DNAS rejects the update the following way
Title update rejected - value not allowed: - Artist - Track

When 'Stream Label: Show - Artist - Title' is selected, Libretime generates the titles with two leading dashes, and then ShoutCAST DNAS rejects the update the following way

Title update rejected - value not allowed: - - Artist - Track

When 'Stream Label: Station name - Show name' is selected, Libretime generates the following;

Title update [Station Name -]

ShoutCAST DNAS accepts this, because it doesn't start with a dash.. neither does it contain any show info..

Icecast in the same setup clearly doesn't care about dashes and is proudly displaying it variously;

Stream Name: Station Name
Currently playing: - Artist - Title
Currently playing: -  - Artist - Title
Currently playing:Station Name - 

Has anyone else successfully connected to ShoutCAST with ID3/ICY data from libretime ?

Is it possible to stop libretime from passing ID3/ICY data to ShoutCAST DNAS (or anything else for that matter) that starts with dashes/special characters by stripping them out ?

If the ID3 field is blank or not passed, can we stop libretime appending a dash to the ID3 data ?

@hairmare
Copy link
Member

Hi @expert-geeks

Welcome to the community!

I didn't know about ShoutCAST's limitiations when it comes to dashes in the metadata.

The current Stream Label selection thing is rather limited. We should probably open the feature up in a way that allows for a more configurable label.

Do you tracks have the actual metadata? Some of you example look like data from the id3 tags is missing.

The code that does the actual rendering of the metadata seems to be here:

https://github.com/LibreTime/libretime/blob/b5b24f34641490599851c7b5039bfc25cccd94ca/python_apps/pypo/liquidsoap/ls_lib.liq#L35-L41

Looking at it something sure does look a but fishy and I would need to do some testing to get figured out if this code path is even getting triggered.

I'm not sure if ShoutCAST needs any special consideration in this code. Making the Stream Label configuration more flexible will probably help more stations achieve their goals while also swatting the ShoutCAST specific issues.

@expert-geeks
Copy link
Contributor Author

expert-geeks commented Sep 29, 2017

Hi @hairmare

Thanks for the welcome!

I agree that more flexibility with the metadata and configuration over the way it is presented, is the way forward. Yes the tracks have the metadata, I took out the track data and replaced it with Artist - Title, I'll copy paste some actual logs.

Indeed, I'd found this bit of code and have successfully got ShoutCAST DNAS and YP updated by taking out the artist variable at line 40. i.e.
[("title", "#{m['title']}"), ("mapped", "true")]
I tried adding an additional if clause that checked the artist variable and would just use the title if empty.. but I couldn't get my syntax correct and soap wouldn't start..

HTTP/1.0 200 OK
icy-notice1:<BR>This stream requires <a href="http://www.winamp.com">Winamp</a><BR>
icy-notice2:SHOUTcast DNAS/posix(linux x64) v2.5.5.732<BR>
Accept-Ranges:none
Access-Control-Allow-Origin:*
Cache-Control:no-cache,no-store,must-revalidate,max-age=0
Connection:close
icy-name:DirtyBass.FM
icy-genre:Breakbeat, Electronic, Drum and Bass
icy-br:192
icy-sr:44100
icy-url:http://dirtybass.fm
icy-pub:1
content-type:audio/mpeg
icy-metaint:16384
X-Clacks-Overhead:GNU Terry Pratchett
]
2017-09-28 16:43:09     INFO    [DST 86.31.187.129:52379 sid=1] SHOUTcast 1 client connection accepted. User-Agent: `VLC/2.2.6 LibVLC/2.2.6', UID: 22, GRID: 22
2017-09-28 16:43:09     INFO    [YP] Updating listing details for stream #3 succeeded.
2017-09-28 16:43:09     DEBUG   [STREAMDATA sid=3] Stream still has 1 reference
2017-09-28 16:43:12     INFO    [YP] Updating listing details for stream #1 succeeded.
2017-09-28 16:43:12     DEBUG   [STREAMDATA sid=1] Stream still has 3 references
2017-09-28 16:43:17     INFO    [YP] Updating listing details for stream #4 succeeded.
2017-09-28 16:43:17     DEBUG   [STREAMDATA sid=4] Stream still has 1 reference
2017-09-28 16:43:18     INFO    [YP] Updating listing details for stream #2 succeeded.
2017-09-28 16:43:18     DEBUG   [STREAMDATA sid=2] Stream still has 1 reference
2017-09-28 16:43:19     INFO    [YP] Updating listing details for stream #3 succeeded.
2017-09-28 16:43:19     DEBUG   [STREAMDATA sid=3] Stream still has 1 reference
2017-09-28 16:43:26     INFO    [YP] Updating listing details for stream #4 succeeded.
2017-09-28 16:43:26     DEBUG   [STREAMDATA sid=4] Stream still has 1 reference
2017-09-28 16:45:43     INFO    [SRC 144.76.62.34:35197 sid=1] Title update [now: "Pandorum - Live on DBFM 02-04-2015", next: "borfd - intelligent session 14.02.09"]
2017-09-28 16:45:44     INFO    [SRC 144.76.62.34:35200 sid=2] Title update [now: "Pandorum - Live on DBFM 02-04-2015", next: "borfd - intelligent session 14.02.09"]
2017-09-28 16:45:45     INFO    [SRC 144.76.62.34:35196 sid=3] Title update [now: "Pandorum - Live on DBFM 02-04-2015", next: "borfd - intelligent session 14.02.09"]
2017-09-28 16:45:46     INFO    [SRC 144.76.62.34:35202 sid=4] Title update [now: "Pandorum - Live on DBFM 02-04-2015", next: "borfd - intelligent session 14.02.09"]
2017-09-28 16:45:47     INFO    [SRC 144.76.62.34:35197 sid=1] Title update [LibreTime - offline]
2017-09-28 16:45:48     INFO    [SRC 144.76.62.34:35200 sid=2] Title update [LibreTime - offline]
2017-09-28 16:45:49     INFO    [SRC 144.76.62.34:35196 sid=3] Title update [LibreTime - offline]
2017-09-28 16:45:50     INFO    [SRC 144.76.62.34:35202 sid=4] Title update [LibreTime - offline]
2017-09-28 16:45:51     INFO    [SRC 144.76.62.34:35197 sid=1] Title update [LibreTime - offline]
2017-09-28 16:45:52     INFO    [SRC 144.76.62.34:35200 sid=2] Title update [LibreTime - offline]
2017-09-28 16:45:53     INFO    [SRC 144.76.62.34:35196 sid=3] Title update [LibreTime - offline]
2017-09-28 16:45:54     INFO    [SRC 144.76.62.34:35202 sid=4] Title update [LibreTime - offline]
2017-09-28 16:45:54     INFO    [YP] Updating listing details for stream #1 succeeded.
2017-09-28 16:45:54     DEBUG   [STREAMDATA sid=1] Stream still has 3 references
2017-09-28 16:45:55     WARN    [ADMINCGI sid=1] Title update rejected - value not allowed: -
2017-09-28 16:45:55     INFO    [SRC 144.76.62.34:35197 sid=1] Title update [LibreTime - offline]
2017-09-28 16:45:56     WARN    [ADMINCGI sid=2] Title update rejected - value not allowed: -
2017-09-28 16:45:56     INFO    [SRC 144.76.62.34:35200 sid=2] Title update [LibreTime - offline]
2017-09-28 16:45:57     WARN    [ADMINCGI sid=3] Title update rejected - value not allowed: -
2017-09-28 16:45:57     INFO    [SRC 144.76.62.34:35196 sid=3] Title update [LibreTime - offline]
2017-09-28 16:45:58     WARN    [ADMINCGI sid=4] Title update rejected - value not allowed: -
2017-09-28 16:45:58     INFO    [SRC 144.76.62.34:35202 sid=4] Title update [LibreTime - offline]
2017-09-28 16:45:59     WARN    [ADMINCGI sid=1] Title update rejected - value not allowed: - NeuralNET - The Darkside 09-05-14
2017-09-28 16:45:59     INFO    [SRC 144.76.62.34:35197 sid=1] Title update [LibreTime - offline]
2017-09-28 16:46:00     WARN    [ADMINCGI sid=2] Title update rejected - value not allowed: - NeuralNET - The Darkside 09-05-14
2017-09-28 16:46:00     INFO    [SRC 144.76.62.34:35200 sid=2] Title update [LibreTime - offline]
2017-09-28 16:46:00     INFO    [YP] Updating listing details for stream #2 succeeded.
2017-09-28 16:46:00     DEBUG   [STREAMDATA sid=2] Stream still has 1 reference
2017-09-28 16:46:01     WARN    [ADMINCGI sid=3] Title update rejected - value not allowed: - NeuralNET - The Darkside 09-05-14

@hairmare
Copy link
Member

Maybe something like this instead of line 40? I didn't test it with the LibreTime script though.

  if "#{m['artist']}" != "" then
    [("title", "#{m['artist']} - #{m['title']}"), ("mapped", "true")]
  else
    [("title", "#{m['title']}"), ("mapped", "true")]
  end

It does seem that rewriting this feature won't be as easy as making the whole format string configurable. At it least not if we want to support cases like this hack.

@expert-geeks
Copy link
Contributor Author

expert-geeks commented Sep 30, 2017

I agree rewriting this section to make the output more configurable would be preferable, but I'm a pragmatic man. I was mainly checking that removing the (empty) artist tag would stop the hyphen being appended and get accepted by Shoutcast (which it is).

This is only in the case that the source is 'Webstream' as all the metadata gets lumped into the title field. When streaming mp3's, there is artist data, so using my hack this information is lost and only the title is shown.

I'd tried writing several if statements like the one you suggested, but every time it stops liquidsoap from starting;

 airtime-liquidsoap.service - Airtime Liquidsoap Service
   Loaded: loaded (/etc/systemd/system/airtime-liquidsoap.service; enabled; vendor preset: enabled)
   Active: inactive (dead) (Result: exit-code) since Sat 2017-09-30 10:42:48 BST; 1s ago
  Process: 18064 ExecStart=/usr/bin/airtime-liquidsoap (code=exited, status=1/FAILURE)
 Main PID: 18064 (code=exited, status=1/FAILURE)

Sep 30 10:42:48 hostname systemd[1]: airtime-liquidsoap.service: Unit entered failed state.
Sep 30 10:42:48 hostname systemd[1]: airtime-liquidsoap.service: Failed with result 'exit-code'.
Sep 30 10:42:48 hostname systemd[1]: airtime-liquidsoap.service: Service hold-off time over, scheduling restart.
Sep 30 10:42:48 hostname systemd[1]: Stopped Airtime Liquidsoap Service.
Sep 30 10:42:48 hostname systemd[1]: airtime-liquidsoap.service: Start request repeated too quickly.
Sep 30 10:42:48 hostname systemd[1]: Failed to start Airtime Liquidsoap Service.

I'll have a tinker with the syntax, alternatively we concatenate the artist + title into one variable and then pass that instead.

@hairmare
Copy link
Member

Please keep on tinkering for all I'm concerned 😉 We can use all the feedback we can get on this. Enhancing this feature has been on my mind for a bit since it really only covers a small portion of use cases as it stands so I'm already trying to make up implementation scenarios.

You should be able to find more info on why the script is failing with your changes by looking at the liquidsoap log at /var/log/airtime/pypo-liquidsoap/ls_script.log. You can run the script manually when you work on it doing something like sudo -u www-data airtime-liquidsoap. You can pass the optional --debug flag to this call to get liquidsoap to output more details.

Passing a pre concatenated variable is probably the best way to make the output syntax configurable. The actual output generation could be in the pypo parts of airtime-playout and then send nice metadata to liquidsoap through the telnet interface.

We could use a template engine like jinja to generate the string in pypo. On the MVC UI side of thing we can keep the existing selection and add an advanced setting with a text area where you can write you own template.

@hairmare
Copy link
Member

hairmare commented Oct 7, 2017

Related: #162

@expert-geeks
Copy link
Contributor Author

expert-geeks commented Feb 27, 2018

Sorry for the late reply.. Didn't get very far initially but got this hack working the other day;
/usr/local/lib/python2.7/dist-packages/airtime_playout-1.0-py2.7.egg/liquidsoap/ls_lib.liq
from line 36

if !stream_metadata_type == 1 then
[("title", "#{!show_name} #{m['artist']} - #{m['title']}"), ("mapped", "true")]
elsif !stream_metadata_type == 2 then
[("title", "#{!station_name} - #{!show_name}"), ("mapped", "true")]
else
if "#{m['artist']}" == "" then
[("title", "#{m['title']}"), ("mapped", "true")]
else
[("title", "#{m['artist']} - #{m['title']}"), ("mapped", "true")]
end
end
end
end

Just a variation on the original suggestion, I don't know why I couldn't get this working originally. This is working for my use case (i.e. streaming webstreams to shoutcast for broadcast) but will fallback to standard behaviour with MP3s as they have data in the artist field. Shall I submit a pull request?

@hairmare
Copy link
Member

hairmare commented Mar 2, 2018

Good to hear that you got it working. A PR would be welcome. I think others have been starting to use shoutCAST lately and this will most likely benefit them as well.

You example seems to have an end to much but I'm pretty sure that that is only a copy-paste error. Please make sure you keep the indentation in line with the rest of the file when you prepare your pull-request.

@expert-geeks
Copy link
Contributor Author

Done! My first PR ;)
#456

@lock
Copy link

lock bot commented Oct 20, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please chat to us on discourse or ask for help on our chat if you have any questions or need further assistance with this issue.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants