Hey, request.resolve() is the operastor you are looking for to test if liquidsoap will accept a file. It should return true when liquidsap will accept the file. (you can also keep the request and use it already resolved in request.dynamic)
As it comes to song length, historically liquidsoap doesn't try to get an exact length. There are compelling reasons for that, most importantly because some formats are hard to predict and/or expensive to compute the length. This is really mostly intended for mp3, which sucks and requires a full decode to have a realistic estimate of a song's length. Liquidsoap gets an estimate of the remaining time. which you can get while the source is playing by calling source.remaining. The closer you get to the end of the track the more accurate it will become. -1 means no known estimate. Another great tool from the ffmpeg suite to deal with song length is ffprobe. You can have it scan a file and return a JSON payload with a lot of information, including the song's total duration. Finally, if you really need a very precise duration estimate within liquidsoap, one route to go down could be to first entirely decode the file before sending it to the streaming engine. This can be done with a custom protocol since I believe 1.3.3. The `ffmpeg2wav` protocol does just that and you should be able to use simply by prefixing your request with it, e.g.: ffmpeg2wav:/path/to/file The resulting wav file should be decodable by liquidsoap and, if length still isn't accurate, that's a format we could definitely work on making precise. Hope this helps, Romain Le mar. 19 févr. 2019 à 08:20, Robbt <ro...@azone.org> a écrit : > Hey Liquidsoap crew, > > This is more of a question coming at things from the LibreTime > experience with Liquidsoap. We occasionally have issues where tracks end > prematurely and then our python based interface screws things up and > ends up scheduling tracks when they shouldn't play and then it fails to > tell liquidsoap to play something new. See - > https://github.com/LibreTime/libretime/issues/699 > > It basically ends up in a cascade of failures where our schedule is > playing shows like 45 minutes after they should have ended. > > It all seems to occur with End of track before cue-out point which was > also mentioned on this bug > https://github.com/savonet/liquidsoap/issues/66 > > This whole scenario is kind of a nightmare from a broadcast perspective > and probably has to do with the loose coupling between the web interface > and the liquidsoap playout inherent in the design we inherited from > airtime. > > Some of the bugs are probably in the python module airtime-playout that > provides the interface between the schedule on our php based web > platform and liquidsoap. I plan on diving into how it is working and > hopefully improving it and avoid some of these errors or at least catch > them and get things back on track sooner. > > We have an issue where our airtime_analyzer doesn't validate the track > length in a way that causes dead air - basically if a file is incomplete > or was cut off and it doesnt match the length the id3 tags say it should > have it will give the error above because it will die before the cut out > point see - https://github.com/LibreTime/libretime/issues/537 > > My ultimate question for liquidsoap at this point is whether there is a > way to test the ability of liquidsoap to parse a file and get what it > sees as the length etc ahead of time. This way we could in theory > integrate this into our analyzer script so that we can reject tracks > that will fail to play or will play with incorrect length. Relying upon > mutagen to analyze the metadata is insufficient to determine whether a > track will actually play as we can see by the bug with the issue of dash > formatted m4a files - see https://github.com/savonet/liquidsoap/issues/713 > > I also need to understand how the integration of ffmpeg works with > liquidsoap as a decoder/parser are there any docs on this, i tried > searching liquidsoap.info but did not see anything. > > Thanks for any help on this. > > Robbt > > > > _______________________________________________ > Savonet-users mailing list > Savonet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/savonet-users >
_______________________________________________ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
