Track Length Info Sent to Live365

[dashford]

There's been a long-standing problem with the data that RB sends (or doesn't send) to Live365.  Back in November 2010 you indicated that the format for the HTTP (GET) text for Live365 should be:

http://tools.live365.com/cgi-bin/add_song.cgi?version=2&pass=MYPASSWORD&handle=MYLOGIN&title=%title&artist=%artist&album=%album

You also said the "seconds" and "filename" fields are not yet available.  So it's not clear how Live365 gets the track length info.  (Their specs say they are expecting the seconds info in the HTTP (GET) text.)  Is the seconds field working now?

Here's the problem we currently have without the seconds field: for very long tracks (greater than 99 minutes) the data gets garbled -- a two-hour talk show that runs 118:30 is displayed in Live365 as running 660:30!  Similarly, a three-hour show of 182:10 ends up as 1080:10.  It seems at some point in the process the track length is in mmm:ss format but is interpreted as hhmmss (with disastrous results).   But anything under 100 minutes is fine, so I'm not completely sure I have a full grasp of what's going on...

 

[djsoft]

The %seconds and %filename fields will be added in the next update - RadioBOSS 4.7.2. I suppose Live365 calculates track length by looking up it in the database for track/title.

Could you please post a link to Live365 specs you were referring to?

 

[dashford]

Well, they say it's actually for relay broadcasters using SAM but the format of the URL is otherwise identical to what you've indicated:

http://wiki.live365.com/pmwiki.php?n=Broadcasting.SubmitTheID3TagsInLiveMode

 

[djsoft]

Thanks for the link.

It doesn't matter which program sends the request. So we'll just add "seconds" and "filename" fields for the request. Though I'm not sure how "filename" could be used by Live365...

 

[dashford]

Great, thanks!

 

[dashford]

The %seconds and %filename fields will be added in the next update - RadioBOSS 4.7.2. I suppose Live365 calculates track length by looking up it in the database for track/title.

Thank you for adding these fields in version 4.7.2.  Unfortunately it doesn't seem to have fixed the problem for the seconds field.

We're finding that when we send Live365 the URL with a hardcoded number of seconds (seconds=7190) for a 1:59:50 program, Live365 reads this correctly and displays [119:50] for the length.  However, when we use (seconds=%seconds) in the URL for the same length program, Live365 displays [660:50] for the length.  Are you sure there is no difference in the URL strings between the hardcoded and the %seconds field version?

(Again, not to beat a dead horse but this is only an issue with tracks greater than 99 minutes in length.)

 

[djsoft]

That's really odd. I checked the request it makes for a 120:39 file and it was "...%seconds=7239", as it should. And there's no difference if a call is made with hardcoded value or %seconds...

As I mentioned in a reply to another thread, if Live365 doesn't support UTF-8 encoding, switch it to ANSI in the HTTP request settings - maybe it's a source of problem.
You can also post a request you're using, probably something is wrong there.

 

[dashford]

That's really odd. I checked the request it makes for a 120:39 file and it was "...%seconds=7239", as it should. And there's no difference if a call is made with hardcoded value or %seconds...

As I mentioned in a reply to another thread, if Live365 doesn't support UTF-8 encoding, switch it to ANSI in the HTTP request settings - maybe it's a source of problem.
You can also post a request you're using, probably something is wrong there.

Here is the request we're sending -- I'm afraid you'll find it's the standard format:

http://tools.live365.com/cgi-bin/add_song.cgi?version=2&pass=[password]&handle=[username]&title=%title&artist=%artist&album=%album&seconds=%seconds

You may remember we had (and *still* have) a very similar problem last year when we tried to pass the contents of the %comment field (to display customized album cover art based on a URL in the comment field of the mp3).  You said that using the %comment field for the URL or hardcoding the URL made no difference -- the strings that were sent were identical.  Yet when those strings were sent to Live365, the art was shown only when the URL was hardcoded -- getting the URL from the %comment field didn't work (and still doesn't).  Same thing here: hardcoding the track length works for Live365; using the %seconds field doesn't work.

I'm not sure what to say at this point.  I don't have access to a local server so I can't run a test to verify your claim that these fields are being handled correctly.  I certainly know that Live365 sees a difference between hardcoding the values and getting the values from the tag fields.

 

[djsoft]

Did you try switching the encoding to "ASCII" in the HTTP request settings?
When using UTF-8 it performs some conversions, and, if Live365 doesn't handle it correctly, this could lead to an undefined behavior. Please see the picture.

 

[djsoft]

Here's a way to test what request is being sent:

- add new HTTP GET request with the following URL (you can also try add %comment field there):

http://www.djsoft.net/1.php?version=2&pass=[password]&handle=[username]&title=%title&artist=%artist&album=%album&seconds=%seconds

- to check what request was actually made (it will show the last request), visit this page:
http://www.djsoft.net/1.php

I tried several times, but there's no difference between hardcoded values and %seconds macro...

 

[dashford]

Did you try switching the encoding to "ASCII" in the HTTP request settings?

Thanks, this *does* seem to be working.  And thanks for providing a way to check the results of sending the string.

Would it be possible to have a single HTTP GET request with different versions of the URL, depending on which folder the track resides in? (or perhaps the contents of a tag field, if it's easier)  We'd like to send the station logo as the "album cover art" (coverURL=...) for station IDs, but omit that parameter if it's a music track and let Live365 do its standard album cover lookup.  Thanks.

 

[djsoft]

Thanks, this *does* seem to be working.  And thanks for providing a way to check the results of sending the string.

That's good! It seems Live365 doesn't like UTF8 encoding. I've updated the FAQ to reflect this.

Would it be possible to have a single HTTP GET request with different versions of the URL, depending on which folder the track resides in? (or perhaps the contents of a tag field, if it's easier)  We'd like to send the station logo as the "album cover art" (coverURL=...) for station IDs, but omit that parameter if it's a music track and let Live365 do its standard album cover lookup.  Thanks.

Changing HTTP request based on conditions will require some kind of scripting...
What happens if the "coverURL" parameter is an empty string - Live365 doesn't show cover at all, or performs lookup?

 

[dashford]

What happens if the "coverURL" parameter is an empty string - Live365 doesn't show cover at all, or performs lookup?

It doesn't show the cover at all, unfortunately -- Live365 apparently expects/requires a valid URL if the coverURL parameter is included.

 

[djsoft]

It doesn't show the cover at all, unfortunately -- Live365 apparently expects/requires a valid URL if the coverURL parameter is included.

That's bad...
I've added it to the request list, probably this will be implemented in the future.

 

[dashford]

It doesn't show the cover at all, unfortunately -- Live365 apparently expects/requires a valid URL if the coverURL parameter is included.

That's bad...
I've added it to the request list, probably this will be implemented in the future.

I can ask no more than that -- thanks!

 

[dashford]

Thanks, this *does* seem to be working.  And thanks for providing a way to check the results of sending the string.

That's good! It seems Live365 doesn't like UTF8 encoding. I've updated the FAQ to reflect this.

Actually, I've found a post from Live365's Director of Engineering that spells out all the parameters (including optional ones) for the add_song.cgi call.

http://forums.live365.com/viewtopic.php?t=58468

There is an optional "charset" parameter that can be set to ISO-8859-1 (the default) or UTF-8.  So it seems you *can* send UTF-8 if you want.

I may play around with the coverURL/visualURL parameters to see if I can get Live365 to use a valid URL for displaying cover art and ignore an invalid URL in favor of its standard lookup.

 

[djsoft]

Actually, I've found a post from Live365's Director of Engineering that spells out all the parameters (including optional ones) for the add_song.cgi call.

http://forums.live365.com/viewtopic.php?t=58468

It says the post was removed... Can you post its contents here?

 

[dashford]

Hmmm, I guess you have to be logged onto their board to see posts.  It's kind of long but here are the notes:

-------

Playlist Update Using add_song.cgi

Use this program to report metadata for the current song playing on a Live365 station to the Live365 servers, where it is logged by the streaming server and sent on for display in the Live365 Player Window. Live365 streaming server logs are analyzed to provide accurate feedback to broadcasters and are essential for the proper assignment of artist and composer royalties. Accurate playlist information is also vital to ensuring that all Live365 stations keep within the guidelines specified in the DMCA.

URL:
http://www.live365.com/cgi-bin/add_song.cgi

Parameters:
version=2
charset=ISO-8859-1|UTF-8

member_name=fred
password=secret
- or -
sessionid=fred:12345

filename=beatles_-_yesterday_-_one.mp3
seconds=203
title=Yesterday
artist=Beatles
album=One

coverURL=<Cover art URL>
-or-
visualURL=[id=<Live365 TrackID>|img=<Cover art URL>]
-or-
asin=<Amazon ASIN>

trackType=ad|<none>
clickThruURL=<click-through URL>
description=Text of ad

Parameter Explanations:
version=2
Version number of this API call. Must be 2.

charset=ISO-8859-1|UTF-8
Character set used to encode user-generated data. If not specified, defaults to ISO-8859-1 (i.e. Latin1). All track metadata fields (i.e. title, album, and artist) are affected by this selection.

member_name=fred
fred is the Live365 member name. Used with password parameter.

password=secret
The password for the account. Used with member_name parameter.

sessionid=membername:sessionkey
An active sessionid may be used in lieu of member_name and password. In that case, the sessionid value should be the same as was returned from an api_login.cgi call.

filename=beatles_-_yesterday_-_one.mp3
MP3 file name. If no other metadata is available, Live365 will try to parse this name to produce a reasonable set of data for display.

seconds=203
Length of the track in seconds. This is a critically important field, as it informs the Player Window on how long to display this track metadata before refreshing. If unknown, set this field to a fairly short period of time, say 120 seconds, so that each listener?s metadata display updates within a reasonable amount of time without placing too high a burden our the Live365 servers.

title=Yesterday
Track title, typically from ID3 tag info. For station IDs, PSAs, DJ announcements or similar non-music tracks, title should contain the text to be displayed in the playlist of the station.

artist=Beatles
Artist, typically from ID3 tag info. Set to ID/PSA for station IDs, PSAs, DJ announcements or similar non-music tracks.

album=One
Album name, typically from ID3 tag info. Set to ID/PSA for station IDs, PSAs, DJ announcements or similar non-music tracks; set to single for music tracks not originally from a specific album or similar work of art.


There are three ways to specify the cover art image to be displayed while this track is playing. Images should be square and roughly 125x125 in size and delivered from a web server that can support the load of all of a station?s audience members requesting a new image with every track change. The caller must have secured rights to use copyrighted images in a commercial setting like Live365 and the Live365 Community Standards apply to all images referenced in this manner.

coverURL=<Cover art URL>
URL of cover art image, e.g. http://cdbaby.name/b/o/boxset.jpg. Be sure that the URL is properly escaped!

visualURL=[id=<Live365 TrackID>|img=<Cover art URL>]
Optional field describing additional track metadata used primarily for display of cover art and to assist with tracking BUY button usage and queries for additional information. Information is arranged as a set of pipe-separated name/value pairs. Existing subfields include:
id=<Live365 TrackID>
Internal Live365 track identifier.
img=<Cover art URL>
URL of cover art image

asin=<Amazon ASIN>
Amazon Standard Indentification Number of the work of art that the track comes from, e.g. B000002O81. The ASIN may refer to a CD, LP, MP3 download, DVD or just about anything else Amazon sells.


For broadcasts that include their own in-stream audio ads, there are some additional input parameters:

trackType=ad|<none>
Optional field describing type of track. Set to ad for in-stream audio ads.

clickThruURL=<click-through URL>
Optional field describing click-through URL associated with this entry. Be sure to properly escape this parameter value.

description=Text of ad
Optional field describing text entry associated with this entry. If you use this parameter, do not include title, artist or album. Be sure to properly escape this parameter value.

 

[djsoft]

Thanks for reposting. I'll add that syntax to the Live 365 FAQ.

Regarding the coverURL, there's a solution.
You can do a HTTP request to a script on your own web site. The script will accept all parameters, filter them (eg. don't include the "coverURL" parameter if it's empty), and then script will make a modified request to Live365 server.

This solution is a good one: we don't overload the RadioBOSS UI with Live365-specific controls, while any kind of logic could be implemented in a "proxy" script.

Let me know if you need any help on this.

 

[dashford]

Thanks for reposting. I'll add that syntax to the Live 365 FAQ.

Regarding the coverURL, there's a solution.
You can do a HTTP request to a script on your own web site. The script will accept all parameters, filter them (eg. don't include the "coverURL" parameter if it's empty), and then script will make a modified request to Live365 server.

This solution is a good one: we don't overload the RadioBOSS UI with Live365-specific controls, while any kind of logic could be implemented in a "proxy" script.

Let me know if you need any help on this.

Do you mean there is a way for RB to initiate a script on our broadcast computer to send an HTTP request to Live365?  We already have a script set up to *manually* send info to Live365, but if RB can "trigger" the script at the start of each track and pass along the parameters needed that would be very useful.  Please let us know.