Hi,
> 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
I'm not sure if that's what you're looking for but liquidsoap's `-r` option
can help you see how a request would be resolved
example:
```
liquidsoap -r "file://tmp/file.mp3"
Request resolved.
rid="0"
status="ready"
initial_uri="file://tmp/file.mp3"
temporary="false"
filename="tmp/file.mp3"
decoder="MAD"
kind="{audio=0+;video=0+;midi=0+}"
Computing duration: 598.80 sec.
```
A blank file with a mp3 extension would produce `Computing duration:
failed.`
You could try this with the files mentioned in
https://github.com/savonet/liquidsoap/issues/713
Thibault
On Tue, Feb 19, 2019 at 2:20 PM Robbt <ro...@azone.org> wrote:
> 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
