Hi all, (Coming back from a very long week-end..)
2012/2/21 Damien Moody <[email protected]>: > Well, your suggestion is showing where the problem is, if not what it > is. > > liquidsoap -r "url" resulted in a "Request resolution timeout". I don't > have this problem when running LS from my radio script, though. I'm not > worried about this part of it. > > liquidsoap -r "file", after downloading the file, the exact command of > which is > > liquidsoap -r download.php\?id\=19535 > > resulted in this: > > Request resolved. > temporary="false" > decoder="MP3" > kind="{audio=0+;video=0+;midi=0+}" > rid="0" > initial_uri="download.php?id=19535" > status="ready" > filename="download.php?id=19535" > Computing duration: 3685.51 sec. > > Now, when I rename the file to "download.mp3" and do liquidsoap -r > download.mp3, everything works as expected: > > Request resolved. > title="Episode 1" > temporary="false" > decoder="MP3" > artist="Jez" > kind="{audio=0+;video=0+;midi=0+}" > rid="0" > tracknumber="1" > initial_uri="download.mp3" > year="2009" > status="ready" > filename="download.mp3" > genre="Ambient Experimental Electronic" > album="Adventures In Sound" > Computing duration: 3685.51 sec. > > This was all from the file I referenced earlier: > http://electro-music.com/forum/download.php?id=19535 > > In version 0.9.3, LS renamed files using some kind of extension of its > own - I don't remember what it was. I had no trouble with metadata > from downloading files of this URL format in 0.9.3. It > looks like 1.0.0 doesn't rename downloaded files any more, and this is > causing the problem somehow. > > Progress! What do you recommend next? Bug? Feature request? I'm hoping > I don't have to go back to 0.9.3, but I do need my radio station to > handle metadata for files downloaded in this way, and 0.9.3 does do the > job... Thanks for investigating this. The problem is exactly the same as previously explained for audio decoder, except that we are talking about metadata decoder instead. Metadata decoding is done using taglib exactly as for audio decoders: using file extension and/or mime type, if available. Also, as explained before, the mp3 format is not a nice format for automatic detection, therefore, it is strongly advised to keep working with .mp3 extension when dealing with mp3 tracks. Here, the main reason is the .php extension from your download link. Therefore, I would primarily investigate a way to obtain links of the form: foo.mp3?id=1234 Or: /1234.mp3 ----> download.php?id=1234 I am pretty sure that apache's regexp engine can handle the latest case. This would make things much easier on many levels. Also, if you really cannot change your links URLs, you may be able to hack around the request.* functions but I am not so sure about this. Otherwise, the usual path is: * Download a file and make sure it has a .php extension. * Check with file -i /path/to/file.php what is the returned mime-type * Add this mime-type to the following configuration key: set("decoder.mime_types.taglib",["audio/mpeg", "some/value"]) This should tell liquidsoap to try to decode metadata for those files using taglib. However, taglib also has its own automatic format detection/guess, which may very well fail as well, still because the mp3 format is loosy and you do not have a .mp3 extension. Hope this helps and good luck, Romain ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
