Re: [Savonet-users] add_protocol issue
Tested on another bionic / 1.3.4 installation:
Warning: unused variable night at line 19, character 9.
Warning: unused variable day at line 18, character 9.
2018/09/24 18:08:22 >>> LOG START
2018/09/24 18:08:22 [main:3] Liquidsoap 1.3.4
2018/09/24 18:08:22 [main:3] Using: bytes=[distributed with OCaml 4.02 or
above] pcre=7.3.4 dtools=0.4.1 duppy=0.7.3 duppy.syntax=0.7.3 cry=0.6.2
mm=0.4.0 ogg=0.5.2 vorbis=0.7.1 mad=0.4.5 dynlink=[distributed with Ocaml]
lame=0.3.3 alsa=0.2.3 samplerate=0.1.4 taglib=0.3.3 camomile=1.0.1
2018/09/24 18:08:22 [dynamic.loader:3] Could not find dynamic module for
fdkaac encoder.
2018/09/24 18:08:22 [frame:3] Using 44100Hz audio, 25Hz video, 44100Hz
master.
2018/09/24 18:08:22 [frame:3] Frame size must be a multiple of 1764 ticks =
1764 audio samples = 1 video samples.
2018/09/24 18:08:22 [frame:3] Targetting 'frame.duration': 0.04s = 1764
audio samples = 1764 ticks.
2018/09/24 18:08:22 [frame:3] Frames last 0.04s = 1764 audio samples = 1
video samples = 1764 ticks.
2018/09/24 18:08:22 [video.converter:4] Couldn't find preferred video
converter: gavl.
2018/09/24 18:08:22 [audio.converter:4] Using preferred samplerate
converter: libsamplerate.
2018/09/24 18:08:22 [threads:3] Created thread "generic queue #1".
2018/09/24 18:08:22 [threads:3] Created thread "generic queue #2".
2018/09/24 18:08:22 [threads:3] Created thread "non-blocking queue #1".
2018/09/24 18:08:22 [threads:3] Created thread "non-blocking queue #2".
2018/09/24 18:08:22 [clock:4] Currently 1 clocks allocated.
2018/09/24 18:08:22 [clock.wallclock_alsa:4] Starting 1 sources...
2018/09/24 18:08:22 [source:4] Source output.alsa_6073 gets up.
2018/09/24 18:08:22 [source:4] Source playlist_6069 gets up.
2018/09/24 18:08:22 [test::3] Loading playlist...
2018/09/24 18:08:22 [protocol.process:4] Processing txt,echo ./test.mp3 >>
$(output)
2018/09/24 18:08:22 [protocol.process:4] Executing echo ./test.mp3 >>
"/tmp/liq-processf0f1bc.txt"
2018/09/24 18:08:22 [lang.run_process:4] Starting process
2018/09/24 18:08:22 [lang.run_process:4] Closing process's stdin
Segmentation fault (core dumped)
Le dim. 23 sept. 2018 à 20:27, Romain Beauxis a
écrit :
> That's strange..
>
> Can you get a request.trace through telnet ?
>
> Also, what OS/OCaml version are you using?
>
> Le dim. 23 sept. 2018 à 13:23, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
>
>> Same with 1.3.4 :(
>>
>> Issue is somewhere else ...
>>
>> 2018/09/23 20:21:04 >>> LOG START
>> 2018/09/23 20:21:04 [main:3] Liquidsoap 1.3.4
>> 2018/09/23 20:21:04 [main:3] Using: bytes=[distributed with OCaml 4.02 or
>> above] pcre=7.3.4 dtools=0.4.0 duppy=0.7.1 duppy.syntax=0.7.1 cry=0.6.2
>> mm=0.4.0 ogg=0.5.2 vorbis=0.7.1 mad=0.4.5 dynlink=[distributed with Ocaml]
>> lame=0.3.3 alsa=0.2.3 samplerate=0.1.4 taglib=0.3.3 camomile=1.0.1
>> 2018/09/23 20:21:04 [dynamic.loader:3] Could not find dynamic module for
>> fdkaac encoder.
>> 2018/09/23 20:21:04 [decoder:3] Method "MAD" accepted
>> "default/single.mp3".
>> 2018/09/23 20:21:04 [frame:3] Using 44100Hz audio, 25Hz video, 44100Hz
>> master.
>> 2018/09/23 20:21:04 [frame:3] Frame size must be a multiple of 1764 ticks
>> = 1764 audio samples = 1 video samples.
>> 2018/09/23 20:21:04 [frame:3] Targetting 'frame.duration': 0.04s = 1764
>> audio samples = 1764 ticks.
>> 2018/09/23 20:21:04 [frame:3] Frames last 0.04s = 1764 audio samples = 1
>> video samples = 1764 ticks.
>> 2018/09/23 20:21:04 [threads:3] Created thread "generic queue #1".
>> 2018/09/23 20:21:04 [threads:3] Created thread "generic queue #2".
>> 2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #1".
>> 2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #2".
>> 2018/09/23 20:21:04 [nc::3] Loading playlist...
>> 2018/09/23 20:21:24 [protocol.process:3] Failed to execute echo
>> ./test.mp3 >> "/tmp/liq-process65471a.txt": ("timeout","19.3759880066")
>> 2018/09/23 20:21:24 [nc::2] Timeout when resolving playlist URI "nc:"!
>> 2018/09/23 20:21:24 [nc::3] Successfully loaded a playlist of 0 tracks.
>> 2018/09/23 20:21:24 [threads:3] Created thread "alsa_out(default)" (1
>> total).
>> 2018/09/23 20:21:24 [threads:3] Created thread "wallclock_alsa" (2 total).
>> 2018/09/23 20:21:24 [clock.wallclock_alsa:3] Streaming loop starts,
>> synchronized by active sources.
>> 2018/09/23 20:21:24 [alsa_out(default):3] Source failed (no more tracks)
>> stopping output...
>> 2018/09/23 20:21:24 [alsa_out(default):3] Using ALSA 1.1.3.
>> 2018/09/23 20:21:24 [alsa_out(default):2] Falling back on interleaved
>> S16LE
>> 2018/09/23 20:21:24 [alsa_out(default):3] Samplefreq=44100Hz,
>> Bufsize=1048576B, Frame=4B, Periods=1024
>> 2018/09/23 20:21:24 [threads:3] Thread "alsa_out(default)" terminated (1
>> remaining).
>>
>>
>> Le dim. 23 sept. 2018 à 20:13, sébastien dagnicourt <
>> sebastien.dagnico...@gmail.com> a écrit :
>>
>>> Hi,
>>>
>>> I tested something like your script, and it failed.
>>>
>>> def nextcloud(~rlog,~maxtime,arg) =
>>>
Re: [Savonet-users] add_protocol issue
request.trace 1
[2018/09/24 17:45:30] Pushed ["test:";...].
[2018/09/24 17:45:30] Resolving "test:" (timeout 20s)...
[2018/09/24 17:45:30] Pushed ["process:txt,echo ./test.mp3 >>
$(output)";...].
[2018/09/24 17:45:30] Resolving "process:txt,echo ./test.mp3 >> $(output)"
(timeout 20s)...
[2018/09/24 17:45:30] Processing txt,echo ./test.mp3 >> $(output)
[2018/09/24 17:45:30] Executing echo ./test.mp3 >>
"/tmp/liq-processd0b470.txt"
Le dim. 23 sept. 2018 à 20:27, Romain Beauxis a
écrit :
> That's strange..
>
> Can you get a request.trace through telnet ?
>
> Also, what OS/OCaml version are you using?
>
> Le dim. 23 sept. 2018 à 13:23, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
>
>> Same with 1.3.4 :(
>>
>> Issue is somewhere else ...
>>
>> 2018/09/23 20:21:04 >>> LOG START
>> 2018/09/23 20:21:04 [main:3] Liquidsoap 1.3.4
>> 2018/09/23 20:21:04 [main:3] Using: bytes=[distributed with OCaml 4.02 or
>> above] pcre=7.3.4 dtools=0.4.0 duppy=0.7.1 duppy.syntax=0.7.1 cry=0.6.2
>> mm=0.4.0 ogg=0.5.2 vorbis=0.7.1 mad=0.4.5 dynlink=[distributed with Ocaml]
>> lame=0.3.3 alsa=0.2.3 samplerate=0.1.4 taglib=0.3.3 camomile=1.0.1
>> 2018/09/23 20:21:04 [dynamic.loader:3] Could not find dynamic module for
>> fdkaac encoder.
>> 2018/09/23 20:21:04 [decoder:3] Method "MAD" accepted
>> "default/single.mp3".
>> 2018/09/23 20:21:04 [frame:3] Using 44100Hz audio, 25Hz video, 44100Hz
>> master.
>> 2018/09/23 20:21:04 [frame:3] Frame size must be a multiple of 1764 ticks
>> = 1764 audio samples = 1 video samples.
>> 2018/09/23 20:21:04 [frame:3] Targetting 'frame.duration': 0.04s = 1764
>> audio samples = 1764 ticks.
>> 2018/09/23 20:21:04 [frame:3] Frames last 0.04s = 1764 audio samples = 1
>> video samples = 1764 ticks.
>> 2018/09/23 20:21:04 [threads:3] Created thread "generic queue #1".
>> 2018/09/23 20:21:04 [threads:3] Created thread "generic queue #2".
>> 2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #1".
>> 2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #2".
>> 2018/09/23 20:21:04 [nc::3] Loading playlist...
>> 2018/09/23 20:21:24 [protocol.process:3] Failed to execute echo
>> ./test.mp3 >> "/tmp/liq-process65471a.txt": ("timeout","19.3759880066")
>> 2018/09/23 20:21:24 [nc::2] Timeout when resolving playlist URI "nc:"!
>> 2018/09/23 20:21:24 [nc::3] Successfully loaded a playlist of 0 tracks.
>> 2018/09/23 20:21:24 [threads:3] Created thread "alsa_out(default)" (1
>> total).
>> 2018/09/23 20:21:24 [threads:3] Created thread "wallclock_alsa" (2 total).
>> 2018/09/23 20:21:24 [clock.wallclock_alsa:3] Streaming loop starts,
>> synchronized by active sources.
>> 2018/09/23 20:21:24 [alsa_out(default):3] Source failed (no more tracks)
>> stopping output...
>> 2018/09/23 20:21:24 [alsa_out(default):3] Using ALSA 1.1.3.
>> 2018/09/23 20:21:24 [alsa_out(default):2] Falling back on interleaved
>> S16LE
>> 2018/09/23 20:21:24 [alsa_out(default):3] Samplefreq=44100Hz,
>> Bufsize=1048576B, Frame=4B, Periods=1024
>> 2018/09/23 20:21:24 [threads:3] Thread "alsa_out(default)" terminated (1
>> remaining).
>>
>>
>> Le dim. 23 sept. 2018 à 20:13, sébastien dagnicourt <
>> sebastien.dagnico...@gmail.com> a écrit :
>>
>>> Hi,
>>>
>>> I tested something like your script, and it failed.
>>>
>>> def nextcloud(~rlog,~maxtime,arg) =
>>> [process_uri(extname="txt","echo ./test.mp3 >> $(output)")]
>>> end
>>> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
>>> syntax="nc://uri")
>>>
>>> Salsa = playlist("nc:")
>>> output.alsa(fallible=true,Salsa)
>>>
>>> 2018/09/23 20:08:06 [nc::3] Loading playlist...
>>> 2018/09/23 20:08:26 [protocol.process:3] Failed to execute echo
>>> ./test.mp3 >> "/tmp/liq-processaa631c.txt": ("timeout","19.7391860485")
>>> 2018/09/23 20:08:26 [nc::2] Failed when resolving playlist URI "nc:"!
>>> 2018/09/23 20:08:26 [nc::3] Successfully loaded a playlist of 0 tracks.
>>>
>>> If I test with a static list like this one '/tmp/liq-processaa631c.txt'
>>> it works so I assume that the "echo" command is well executed and that the
>>> result file is good.
>>>
>>> I check if I can upgrade to 1.3.4
>>>
>>>
>>>
>>> Le dim. 23 sept. 2018 à 18:27, Romain Beauxis
>>> a écrit :
>>>
Hi,
Le sam. 22 sept. 2018 à 13:10, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
>
> Hi,
>
> So new tests:
> I create a local "radio.txt" file.
> I put in in the playlist function, tracks were discovered and played.
>
> So, I created a simple bash file that do a "cat radio.txt >>
tmp_liquidsoap_file"
> Same issue, liquidsoap won't take the file.
> As you suggested I put a debug echo before the exit 0, the echo is
ok. The content of the tmp file is ok.
> Can't do more simple than that ...
That's a good start! This works for me with 1.3.4:
def test(~rlog,~maxtime,arg) =
[process_uri(extname="txt","echo /tmp/bla.wav >> $(output)")]
end
Re: [Savonet-users] add_protocol issue
That's strange..
Can you get a request.trace through telnet ?
Also, what OS/OCaml version are you using?
Le dim. 23 sept. 2018 à 13:23, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
> Same with 1.3.4 :(
>
> Issue is somewhere else ...
>
> 2018/09/23 20:21:04 >>> LOG START
> 2018/09/23 20:21:04 [main:3] Liquidsoap 1.3.4
> 2018/09/23 20:21:04 [main:3] Using: bytes=[distributed with OCaml 4.02 or
> above] pcre=7.3.4 dtools=0.4.0 duppy=0.7.1 duppy.syntax=0.7.1 cry=0.6.2
> mm=0.4.0 ogg=0.5.2 vorbis=0.7.1 mad=0.4.5 dynlink=[distributed with Ocaml]
> lame=0.3.3 alsa=0.2.3 samplerate=0.1.4 taglib=0.3.3 camomile=1.0.1
> 2018/09/23 20:21:04 [dynamic.loader:3] Could not find dynamic module for
> fdkaac encoder.
> 2018/09/23 20:21:04 [decoder:3] Method "MAD" accepted "default/single.mp3".
> 2018/09/23 20:21:04 [frame:3] Using 44100Hz audio, 25Hz video, 44100Hz
> master.
> 2018/09/23 20:21:04 [frame:3] Frame size must be a multiple of 1764 ticks
> = 1764 audio samples = 1 video samples.
> 2018/09/23 20:21:04 [frame:3] Targetting 'frame.duration': 0.04s = 1764
> audio samples = 1764 ticks.
> 2018/09/23 20:21:04 [frame:3] Frames last 0.04s = 1764 audio samples = 1
> video samples = 1764 ticks.
> 2018/09/23 20:21:04 [threads:3] Created thread "generic queue #1".
> 2018/09/23 20:21:04 [threads:3] Created thread "generic queue #2".
> 2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #1".
> 2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #2".
> 2018/09/23 20:21:04 [nc::3] Loading playlist...
> 2018/09/23 20:21:24 [protocol.process:3] Failed to execute echo ./test.mp3
> >> "/tmp/liq-process65471a.txt": ("timeout","19.3759880066")
> 2018/09/23 20:21:24 [nc::2] Timeout when resolving playlist URI "nc:"!
> 2018/09/23 20:21:24 [nc::3] Successfully loaded a playlist of 0 tracks.
> 2018/09/23 20:21:24 [threads:3] Created thread "alsa_out(default)" (1
> total).
> 2018/09/23 20:21:24 [threads:3] Created thread "wallclock_alsa" (2 total).
> 2018/09/23 20:21:24 [clock.wallclock_alsa:3] Streaming loop starts,
> synchronized by active sources.
> 2018/09/23 20:21:24 [alsa_out(default):3] Source failed (no more tracks)
> stopping output...
> 2018/09/23 20:21:24 [alsa_out(default):3] Using ALSA 1.1.3.
> 2018/09/23 20:21:24 [alsa_out(default):2] Falling back on interleaved S16LE
> 2018/09/23 20:21:24 [alsa_out(default):3] Samplefreq=44100Hz,
> Bufsize=1048576B, Frame=4B, Periods=1024
> 2018/09/23 20:21:24 [threads:3] Thread "alsa_out(default)" terminated (1
> remaining).
>
>
> Le dim. 23 sept. 2018 à 20:13, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
>
>> Hi,
>>
>> I tested something like your script, and it failed.
>>
>> def nextcloud(~rlog,~maxtime,arg) =
>> [process_uri(extname="txt","echo ./test.mp3 >> $(output)")]
>> end
>> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
>> syntax="nc://uri")
>>
>> Salsa = playlist("nc:")
>> output.alsa(fallible=true,Salsa)
>>
>> 2018/09/23 20:08:06 [nc::3] Loading playlist...
>> 2018/09/23 20:08:26 [protocol.process:3] Failed to execute echo
>> ./test.mp3 >> "/tmp/liq-processaa631c.txt": ("timeout","19.7391860485")
>> 2018/09/23 20:08:26 [nc::2] Failed when resolving playlist URI "nc:"!
>> 2018/09/23 20:08:26 [nc::3] Successfully loaded a playlist of 0 tracks.
>>
>> If I test with a static list like this one '/tmp/liq-processaa631c.txt'
>> it works so I assume that the "echo" command is well executed and that the
>> result file is good.
>>
>> I check if I can upgrade to 1.3.4
>>
>>
>>
>> Le dim. 23 sept. 2018 à 18:27, Romain Beauxis
>> a écrit :
>>
>>> Hi,
>>> Le sam. 22 sept. 2018 à 13:10, sébastien dagnicourt <
>>> sebastien.dagnico...@gmail.com> a écrit :
>>> >
>>> > Hi,
>>> >
>>> > So new tests:
>>> > I create a local "radio.txt" file.
>>> > I put in in the playlist function, tracks were discovered and played.
>>> >
>>> > So, I created a simple bash file that do a "cat radio.txt >>
>>> tmp_liquidsoap_file"
>>> > Same issue, liquidsoap won't take the file.
>>> > As you suggested I put a debug echo before the exit 0, the echo is ok.
>>> The content of the tmp file is ok.
>>> > Can't do more simple than that ...
>>>
>>> That's a good start! This works for me with 1.3.4:
>>>
>>> def test(~rlog,~maxtime,arg) =
>>> [process_uri(extname="txt","echo /tmp/bla.wav >> $(output)")]
>>> end
>>> add_protocol("test",test)
>>>
>>> s = playlist("test:")
>>>
>>> output.ao(fallible=true,s)
>>>
>>> Is that similar to your test?
>>> Romain
>>> ___
>>> 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
>
___
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
Re: [Savonet-users] add_protocol issue
Same with 1.3.4 :(
Issue is somewhere else ...
2018/09/23 20:21:04 >>> LOG START
2018/09/23 20:21:04 [main:3] Liquidsoap 1.3.4
2018/09/23 20:21:04 [main:3] Using: bytes=[distributed with OCaml 4.02 or
above] pcre=7.3.4 dtools=0.4.0 duppy=0.7.1 duppy.syntax=0.7.1 cry=0.6.2
mm=0.4.0 ogg=0.5.2 vorbis=0.7.1 mad=0.4.5 dynlink=[distributed with Ocaml]
lame=0.3.3 alsa=0.2.3 samplerate=0.1.4 taglib=0.3.3 camomile=1.0.1
2018/09/23 20:21:04 [dynamic.loader:3] Could not find dynamic module for
fdkaac encoder.
2018/09/23 20:21:04 [decoder:3] Method "MAD" accepted "default/single.mp3".
2018/09/23 20:21:04 [frame:3] Using 44100Hz audio, 25Hz video, 44100Hz
master.
2018/09/23 20:21:04 [frame:3] Frame size must be a multiple of 1764 ticks =
1764 audio samples = 1 video samples.
2018/09/23 20:21:04 [frame:3] Targetting 'frame.duration': 0.04s = 1764
audio samples = 1764 ticks.
2018/09/23 20:21:04 [frame:3] Frames last 0.04s = 1764 audio samples = 1
video samples = 1764 ticks.
2018/09/23 20:21:04 [threads:3] Created thread "generic queue #1".
2018/09/23 20:21:04 [threads:3] Created thread "generic queue #2".
2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #1".
2018/09/23 20:21:04 [threads:3] Created thread "non-blocking queue #2".
2018/09/23 20:21:04 [nc::3] Loading playlist...
2018/09/23 20:21:24 [protocol.process:3] Failed to execute echo ./test.mp3
>> "/tmp/liq-process65471a.txt": ("timeout","19.3759880066")
2018/09/23 20:21:24 [nc::2] Timeout when resolving playlist URI "nc:"!
2018/09/23 20:21:24 [nc::3] Successfully loaded a playlist of 0 tracks.
2018/09/23 20:21:24 [threads:3] Created thread "alsa_out(default)" (1
total).
2018/09/23 20:21:24 [threads:3] Created thread "wallclock_alsa" (2 total).
2018/09/23 20:21:24 [clock.wallclock_alsa:3] Streaming loop starts,
synchronized by active sources.
2018/09/23 20:21:24 [alsa_out(default):3] Source failed (no more tracks)
stopping output...
2018/09/23 20:21:24 [alsa_out(default):3] Using ALSA 1.1.3.
2018/09/23 20:21:24 [alsa_out(default):2] Falling back on interleaved S16LE
2018/09/23 20:21:24 [alsa_out(default):3] Samplefreq=44100Hz,
Bufsize=1048576B, Frame=4B, Periods=1024
2018/09/23 20:21:24 [threads:3] Thread "alsa_out(default)" terminated (1
remaining).
Le dim. 23 sept. 2018 à 20:13, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
> Hi,
>
> I tested something like your script, and it failed.
>
> def nextcloud(~rlog,~maxtime,arg) =
> [process_uri(extname="txt","echo ./test.mp3 >> $(output)")]
> end
> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
> syntax="nc://uri")
>
> Salsa = playlist("nc:")
> output.alsa(fallible=true,Salsa)
>
> 2018/09/23 20:08:06 [nc::3] Loading playlist...
> 2018/09/23 20:08:26 [protocol.process:3] Failed to execute echo ./test.mp3
> >> "/tmp/liq-processaa631c.txt": ("timeout","19.7391860485")
> 2018/09/23 20:08:26 [nc::2] Failed when resolving playlist URI "nc:"!
> 2018/09/23 20:08:26 [nc::3] Successfully loaded a playlist of 0 tracks.
>
> If I test with a static list like this one '/tmp/liq-processaa631c.txt' it
> works so I assume that the "echo" command is well executed and that the
> result file is good.
>
> I check if I can upgrade to 1.3.4
>
>
>
> Le dim. 23 sept. 2018 à 18:27, Romain Beauxis
> a écrit :
>
>> Hi,
>> Le sam. 22 sept. 2018 à 13:10, sébastien dagnicourt <
>> sebastien.dagnico...@gmail.com> a écrit :
>> >
>> > Hi,
>> >
>> > So new tests:
>> > I create a local "radio.txt" file.
>> > I put in in the playlist function, tracks were discovered and played.
>> >
>> > So, I created a simple bash file that do a "cat radio.txt >>
>> tmp_liquidsoap_file"
>> > Same issue, liquidsoap won't take the file.
>> > As you suggested I put a debug echo before the exit 0, the echo is ok.
>> The content of the tmp file is ok.
>> > Can't do more simple than that ...
>>
>> That's a good start! This works for me with 1.3.4:
>>
>> def test(~rlog,~maxtime,arg) =
>> [process_uri(extname="txt","echo /tmp/bla.wav >> $(output)")]
>> end
>> add_protocol("test",test)
>>
>> s = playlist("test:")
>>
>> output.ao(fallible=true,s)
>>
>> Is that similar to your test?
>> Romain
>> ___
>> 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
Re: [Savonet-users] add_protocol issue
Hi,
I tested something like your script, and it failed.
def nextcloud(~rlog,~maxtime,arg) =
[process_uri(extname="txt","echo ./test.mp3 >> $(output)")]
end
add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
syntax="nc://uri")
Salsa = playlist("nc:")
output.alsa(fallible=true,Salsa)
2018/09/23 20:08:06 [nc::3] Loading playlist...
2018/09/23 20:08:26 [protocol.process:3] Failed to execute echo ./test.mp3
>> "/tmp/liq-processaa631c.txt": ("timeout","19.7391860485")
2018/09/23 20:08:26 [nc::2] Failed when resolving playlist URI "nc:"!
2018/09/23 20:08:26 [nc::3] Successfully loaded a playlist of 0 tracks.
If I test with a static list like this one '/tmp/liq-processaa631c.txt' it
works so I assume that the "echo" command is well executed and that the
result file is good.
I check if I can upgrade to 1.3.4
Le dim. 23 sept. 2018 à 18:27, Romain Beauxis a
écrit :
> Hi,
> Le sam. 22 sept. 2018 à 13:10, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
> >
> > Hi,
> >
> > So new tests:
> > I create a local "radio.txt" file.
> > I put in in the playlist function, tracks were discovered and played.
> >
> > So, I created a simple bash file that do a "cat radio.txt >>
> tmp_liquidsoap_file"
> > Same issue, liquidsoap won't take the file.
> > As you suggested I put a debug echo before the exit 0, the echo is ok.
> The content of the tmp file is ok.
> > Can't do more simple than that ...
>
> That's a good start! This works for me with 1.3.4:
>
> def test(~rlog,~maxtime,arg) =
> [process_uri(extname="txt","echo /tmp/bla.wav >> $(output)")]
> end
> add_protocol("test",test)
>
> s = playlist("test:")
>
> output.ao(fallible=true,s)
>
> Is that similar to your test?
> Romain
> ___
> 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
Re: [Savonet-users] add_protocol issue
Hi,
Le sam. 22 sept. 2018 à 13:10, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
>
> Hi,
>
> So new tests:
> I create a local "radio.txt" file.
> I put in in the playlist function, tracks were discovered and played.
>
> So, I created a simple bash file that do a "cat radio.txt >>
tmp_liquidsoap_file"
> Same issue, liquidsoap won't take the file.
> As you suggested I put a debug echo before the exit 0, the echo is ok.
The content of the tmp file is ok.
> Can't do more simple than that ...
That's a good start! This works for me with 1.3.4:
def test(~rlog,~maxtime,arg) =
[process_uri(extname="txt","echo /tmp/bla.wav >> $(output)")]
end
add_protocol("test",test)
s = playlist("test:")
output.ao(fallible=true,s)
Is that similar to your test?
Romain
___
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] add_protocol issue
Hi,
So new tests:
I create a local "radio.txt" file.
I put in in the playlist function, tracks were discovered and played.
So, I created a simple bash file that do a "cat radio.txt >>
tmp_liquidsoap_file"
Same issue, liquidsoap won't take the file.
As you suggested I put a debug echo before the exit 0, the echo is ok. The
content of the tmp file is ok.
Can't do more simple than that ...
Here's my setup:
Liquidsoap 1.3.3
2018/09/22 20:05:06 [main:3] Using: bytes=[distributed with OCaml 4.02 or
above] pcre=7.3.4 dtools=0.4.0 duppy=0.7.1 duppy.syntax=0.7.1 cry=0.6.2
mm=0.4.0 ogg=0.5.2 vorbis=0.7.1 mad=0.4.5 dynlink=[distributed with Ocaml]
lame=0.3.3 alsa=0.2.3 samplerate=0.1.4 taglib=0.3.3 camomile=1.0.1
OS: Ubuntu Bionic.
Le lun. 17 sept. 2018 à 16:51, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
> Sorry, wrong copy paste, was testing something else
>
> Le lun. 17 sept. 2018 16:17, Romain Beauxis a
> écrit :
>
>> Le dim. 16 sept. 2018 à 12:30, sébastien dagnicourt
>> a écrit :
>> >
>> > OK, don't have more time today to tests some more things.
>> >
>> > For the telnet, server trace don't show more than that :
>> > [2018/09/16 19:20:02] Pushed ["nc://genre1/playlist1.txt";...].
>> > [2018/09/16 19:20:02] Resolving "nc://genre1/playlist1" (timeout 30s)...
>> > [2018/09/16 19:20:02] Pushed ["process:.txt,/work/get_file.py
>> '//genre1/playlist1.txt' $(output)";...].
>> > [2018/09/16 19:20:02] Resolving "process:.m3u,/data/djt/ls/get_file.py
>> '//genre1/playlist1.txt' $(output)" (timeout 30s)...
>> > [2018/09/16 19:20:02] Processing .m3u,/work/get_file.py
>> '//genre1/playlist1.txt' $(output)
>>
>> These last 3 lines are suspicious. Why does the extension suddenly
>> change to m3u and why does the process changes to
>> /data/djt/ls/get_file.py and then back to /work/get_file.py?
>>
>> > [2018/09/16 19:20:02] Executing /work/get_file.py
>> '//genre1/playlist1.txt' "/tmp/liq-process81a1c7..m3u"
>> > [2018/09/16 19:20:31] Failed to execute /work/get_file.py
>> '//genre1/playlist1.txt' "/tmp/liq-process81a1c7..m3u":
>> ("timeout","29.8845801353")
>> > [2018/09/16 19:20:31] Every possibility failed!
>> > [2018/09/16 19:20:31] Request finished.
>> > Will do some more tests tomorrow :)
>> >
>> > Le dim. 16 sept. 2018 à 18:42, Romain Beauxis
>> a écrit :
>> >>
>> >>
>> >>
>> >> Le dim. 16 sept. 2018 à 11:27, sébastien dagnicourt <
>> sebastien.dagnico...@gmail.com> a écrit :
>> >> >
>> >> > Yes, I saw that and I had already the same idea ;)
>> >> > No more luck ...
>> >> >
>> >> > How liquidsoap knows that the script got the playlist ? I mean, does
>> the temp file is known by liquidsoap ?
>> >> > I saw in other examples that people are doing something like
>> get_process_line("") to have the result of the command.
>> >>
>> >> Liquidsoap generates the tmp file name, creates a temp file and passes
>> it to the process as the $(output) argument and then waits for the process
>> to terminate.
>> >>
>> >> Looking at your script and considering your issue, it must be that the
>> line:
>> >> oc.get_file(f, fd)
>> >> never returns, since adding exit(0) after it doesn't solve the problem.
>> >>
>> >> To double check on that you may want to add a print statement too and
>> see if it shows up in the logs.
>> >>
>> >> Another thing to check is that perhaps the process returns but the
>> request resolution fails later in the process. You may want to enable the
>> telnet server:
>> >> set("server.telnet",true)
>> >> and check on the request's trace as explained before. There you should
>> have the full logs of the request resolution.
>> >>
>> >> Romain
>> >>
>> >> ___
>> >> 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
>>
>>
>> ___
>> 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
Re: [Savonet-users] add_protocol issue
Sorry, wrong copy paste, was testing something else
Le lun. 17 sept. 2018 16:17, Romain Beauxis a
écrit :
> Le dim. 16 sept. 2018 à 12:30, sébastien dagnicourt
> a écrit :
> >
> > OK, don't have more time today to tests some more things.
> >
> > For the telnet, server trace don't show more than that :
> > [2018/09/16 19:20:02] Pushed ["nc://genre1/playlist1.txt";...].
> > [2018/09/16 19:20:02] Resolving "nc://genre1/playlist1" (timeout 30s)...
> > [2018/09/16 19:20:02] Pushed ["process:.txt,/work/get_file.py
> '//genre1/playlist1.txt' $(output)";...].
> > [2018/09/16 19:20:02] Resolving "process:.m3u,/data/djt/ls/get_file.py
> '//genre1/playlist1.txt' $(output)" (timeout 30s)...
> > [2018/09/16 19:20:02] Processing .m3u,/work/get_file.py
> '//genre1/playlist1.txt' $(output)
>
> These last 3 lines are suspicious. Why does the extension suddenly
> change to m3u and why does the process changes to
> /data/djt/ls/get_file.py and then back to /work/get_file.py?
>
> > [2018/09/16 19:20:02] Executing /work/get_file.py
> '//genre1/playlist1.txt' "/tmp/liq-process81a1c7..m3u"
> > [2018/09/16 19:20:31] Failed to execute /work/get_file.py
> '//genre1/playlist1.txt' "/tmp/liq-process81a1c7..m3u":
> ("timeout","29.8845801353")
> > [2018/09/16 19:20:31] Every possibility failed!
> > [2018/09/16 19:20:31] Request finished.
> > Will do some more tests tomorrow :)
> >
> > Le dim. 16 sept. 2018 à 18:42, Romain Beauxis
> a écrit :
> >>
> >>
> >>
> >> Le dim. 16 sept. 2018 à 11:27, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
> >> >
> >> > Yes, I saw that and I had already the same idea ;)
> >> > No more luck ...
> >> >
> >> > How liquidsoap knows that the script got the playlist ? I mean, does
> the temp file is known by liquidsoap ?
> >> > I saw in other examples that people are doing something like
> get_process_line("") to have the result of the command.
> >>
> >> Liquidsoap generates the tmp file name, creates a temp file and passes
> it to the process as the $(output) argument and then waits for the process
> to terminate.
> >>
> >> Looking at your script and considering your issue, it must be that the
> line:
> >> oc.get_file(f, fd)
> >> never returns, since adding exit(0) after it doesn't solve the problem.
> >>
> >> To double check on that you may want to add a print statement too and
> see if it shows up in the logs.
> >>
> >> Another thing to check is that perhaps the process returns but the
> request resolution fails later in the process. You may want to enable the
> telnet server:
> >> set("server.telnet",true)
> >> and check on the request's trace as explained before. There you should
> have the full logs of the request resolution.
> >>
> >> Romain
> >>
> >> ___
> >> 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
>
>
> ___
> 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
Re: [Savonet-users] add_protocol issue
Le dim. 16 sept. 2018 à 12:30, sébastien dagnicourt
a écrit :
>
> OK, don't have more time today to tests some more things.
>
> For the telnet, server trace don't show more than that :
> [2018/09/16 19:20:02] Pushed ["nc://genre1/playlist1.txt";...].
> [2018/09/16 19:20:02] Resolving "nc://genre1/playlist1" (timeout 30s)...
> [2018/09/16 19:20:02] Pushed ["process:.txt,/work/get_file.py
> '//genre1/playlist1.txt' $(output)";...].
> [2018/09/16 19:20:02] Resolving "process:.m3u,/data/djt/ls/get_file.py
> '//genre1/playlist1.txt' $(output)" (timeout 30s)...
> [2018/09/16 19:20:02] Processing .m3u,/work/get_file.py
> '//genre1/playlist1.txt' $(output)
These last 3 lines are suspicious. Why does the extension suddenly
change to m3u and why does the process changes to
/data/djt/ls/get_file.py and then back to /work/get_file.py?
> [2018/09/16 19:20:02] Executing /work/get_file.py '//genre1/playlist1.txt'
> "/tmp/liq-process81a1c7..m3u"
> [2018/09/16 19:20:31] Failed to execute /work/get_file.py
> '//genre1/playlist1.txt' "/tmp/liq-process81a1c7..m3u":
> ("timeout","29.8845801353")
> [2018/09/16 19:20:31] Every possibility failed!
> [2018/09/16 19:20:31] Request finished.
> Will do some more tests tomorrow :)
>
> Le dim. 16 sept. 2018 à 18:42, Romain Beauxis a
> écrit :
>>
>>
>>
>> Le dim. 16 sept. 2018 à 11:27, sébastien dagnicourt
>> a écrit :
>> >
>> > Yes, I saw that and I had already the same idea ;)
>> > No more luck ...
>> >
>> > How liquidsoap knows that the script got the playlist ? I mean, does the
>> > temp file is known by liquidsoap ?
>> > I saw in other examples that people are doing something like
>> > get_process_line("") to have the result of the command.
>>
>> Liquidsoap generates the tmp file name, creates a temp file and passes it to
>> the process as the $(output) argument and then waits for the process to
>> terminate.
>>
>> Looking at your script and considering your issue, it must be that the line:
>> oc.get_file(f, fd)
>> never returns, since adding exit(0) after it doesn't solve the problem.
>>
>> To double check on that you may want to add a print statement too and see if
>> it shows up in the logs.
>>
>> Another thing to check is that perhaps the process returns but the request
>> resolution fails later in the process. You may want to enable the telnet
>> server:
>> set("server.telnet",true)
>> and check on the request's trace as explained before. There you should have
>> the full logs of the request resolution.
>>
>> Romain
>>
>> ___
>> 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
___
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] add_protocol issue
OK, don't have more time today to tests some more things.
For the telnet, server trace don't show more than that :
[2018/09/16 19:20:02] Pushed ["nc://genre1/playlist1.txt";...].
[2018/09/16 19:20:02] Resolving "nc://genre1/playlist1" (timeout 30s)...
[2018/09/16 19:20:02] Pushed ["process:.txt,/work/get_file.py
'//genre1/playlist1.txt' $(output)";...].
[2018/09/16 19:20:02] Resolving "process:.m3u,/data/djt/ls/get_file.py
'//genre1/playlist1.txt' $(output)" (timeout 30s)...
[2018/09/16 19:20:02] Processing .m3u,/work/get_file.py
'//genre1/playlist1.txt' $(output)
[2018/09/16 19:20:02] Executing /work/get_file.py '//genre1/playlist1.txt'
"/tmp/liq-process81a1c7..m3u"
[2018/09/16 19:20:31] Failed to execute /work/get_file.py
'//genre1/playlist1.txt' "/tmp/liq-process81a1c7..m3u":
("timeout","29.8845801353")
[2018/09/16 19:20:31] Every possibility failed!
[2018/09/16 19:20:31] Request finished.
Will do some more tests tomorrow :)
Le dim. 16 sept. 2018 à 18:42, Romain Beauxis a
écrit :
>
>
> Le dim. 16 sept. 2018 à 11:27, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
> >
> > Yes, I saw that and I had already the same idea ;)
> > No more luck ...
> >
> > How liquidsoap knows that the script got the playlist ? I mean, does the
> temp file is known by liquidsoap ?
> > I saw in other examples that people are doing something like
> get_process_line("") to have the result of the command.
>
> Liquidsoap generates the tmp file name, creates a temp file and passes it
> to the process as the $(output) argument and then waits for the process to
> terminate.
>
> Looking at your script and considering your issue, it must be that the
> line:
> oc.get_file(f, fd)
> never returns, since adding exit(0) after it doesn't solve the problem.
>
> To double check on that you may want to add a print statement too and see
> if it shows up in the logs.
>
> Another thing to check is that perhaps the process returns but the request
> resolution fails later in the process. You may want to enable the telnet
> server:
> set("server.telnet",true)
> and check on the request's trace as explained before. There you should
> have the full logs of the request resolution.
>
> Romain
>
> ___
> 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
Re: [Savonet-users] add_protocol issue
Le dim. 16 sept. 2018 à 11:27, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
>
> Yes, I saw that and I had already the same idea ;)
> No more luck ...
>
> How liquidsoap knows that the script got the playlist ? I mean, does the
temp file is known by liquidsoap ?
> I saw in other examples that people are doing something like
get_process_line("") to have the result of the command.
Liquidsoap generates the tmp file name, creates a temp file and passes it
to the process as the $(output) argument and then waits for the process to
terminate.
Looking at your script and considering your issue, it must be that the line:
oc.get_file(f, fd)
never returns, since adding exit(0) after it doesn't solve the problem.
To double check on that you may want to add a print statement too and see
if it shows up in the logs.
Another thing to check is that perhaps the process returns but the request
resolution fails later in the process. You may want to enable the telnet
server:
set("server.telnet",true)
and check on the request's trace as explained before. There you should have
the full logs of the request resolution.
Romain
___
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] add_protocol issue
Yes, I saw that and I had already the same idea ;)
No more luck ...
How liquidsoap knows that the script got the playlist ? I mean, does the
temp file is known by liquidsoap ?
I saw in other examples that people are doing something like
get_process_line("") to have the result of the command.
Le dim. 16 sept. 2018 à 18:18, Romain Beauxis a
écrit :
>
>
> Le dim. 16 sept. 2018 à 11:08, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
> >
> > OK, just for information, the python script is realy simple:
> >
> > #!/usr/bin/python3
> > import owncloud
> > import sys
> >
> >
> > f = sys.argv[1].replace('ocfl://','')
> > fd = sys.argv[2]
> > oc = owncloud.Client('https://mynextcloud_url')
> > oc.login('login','password')
> > oc.get_file(f, fd)
> >
> > User is the same for launching the liquidsoap command or the python one
> from the shell.
> > The thing I don't understand is that the command works under liquidsoap
> also because I have a good file under /tmp/( the
> "/tmp/liq-process971096..txt" written in the log)
> > It's as if I fecth a file but liquidsoap doesn't know the name of it
> (the one under /tmp)
> > May me I miss something here ?
> >
> > With full debug I have this line :
> > Failed to resolve "process:.txt,/data/djt/ls/get_file.bash
> '//genre1/playlist1.txt' $(output)"! For more info, see server command
> 'trace 1'
> >
> > Btw the only env difference between from liquidsoap or from a shell is
> the LANG variable.
> > Changed it to confirm that it's the same in the end ;)
>
> Ok, here's another thing: the way liquidsoap terminates a program when run
> like this is by closing its standard input and waiting for it to terminate.
> The unix API doesn't give many other ways to do so.
>
> You may want to add an explicit exit(0) at the very end of the script to
> make sure it terminates properly.
>
> Romain
> ___
> 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
Re: [Savonet-users] add_protocol issue
Le dim. 16 sept. 2018 à 11:08, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
>
> OK, just for information, the python script is realy simple:
>
> #!/usr/bin/python3
> import owncloud
> import sys
>
>
> f = sys.argv[1].replace('ocfl://','')
> fd = sys.argv[2]
> oc = owncloud.Client('https://mynextcloud_url')
> oc.login('login','password')
> oc.get_file(f, fd)
>
> User is the same for launching the liquidsoap command or the python one
from the shell.
> The thing I don't understand is that the command works under liquidsoap
also because I have a good file under /tmp/( the
"/tmp/liq-process971096..txt" written in the log)
> It's as if I fecth a file but liquidsoap doesn't know the name of it (the
one under /tmp)
> May me I miss something here ?
>
> With full debug I have this line :
> Failed to resolve "process:.txt,/data/djt/ls/get_file.bash
'//genre1/playlist1.txt' $(output)"! For more info, see server command
'trace 1'
>
> Btw the only env difference between from liquidsoap or from a shell is
the LANG variable.
> Changed it to confirm that it's the same in the end ;)
Ok, here's another thing: the way liquidsoap terminates a program when run
like this is by closing its standard input and waiting for it to terminate.
The unix API doesn't give many other ways to do so.
You may want to add an explicit exit(0) at the very end of the script to
make sure it terminates properly.
Romain
___
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] add_protocol issue
OK, just for information, the python script is realy simple:
#!/usr/bin/python3
import owncloud
import sys
f = sys.argv[1].replace('ocfl://','')
fd = sys.argv[2]
oc = owncloud.Client('https://mynextcloud_url')
oc.login('login','password')
oc.get_file(f, fd)
User is the same for launching the liquidsoap command or the python one
from the shell.
The thing I don't understand is that the command works under liquidsoap
also because I have a good file under /tmp/( the
"/tmp/liq-process971096..txt" written in the log)
It's as if I fecth a file but liquidsoap doesn't know the name of it (the
one under /tmp)
May me I miss something here ?
With full debug I have this line :
Failed to resolve "process:.txt,/data/djt/ls/get_file.bash
'//genre1/playlist1.txt' $(output)"! For more info, see server command
'trace 1'
Btw the only env difference between from liquidsoap or from a shell is the
LANG variable.
Changed it to confirm that it's the same in the end ;)
Le dim. 16 sept. 2018 à 17:40, Romain Beauxis a
écrit :
> Le dim. 16 sept. 2018 à 10:15, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
> > Already tested it with 30 and 60 seconds. The command took under 10
> seconds in a shell so don't know where is my mystake.
> > If i check the file i got un /tmp the content is OK !
>
> Ok. Your next step is to check on environment variables. Does your script
> rely on some environment variables or specific user to run correctly?
>
> The essential difference between running the script in a shell and inside
> the liquidsoap process are the user running it and the environment
> variables passed to it.
>
> Inside liquidsoap, user will be whatever it run as and environment
> variable should be inherited from the parent liquidsoap process. You should
> be able to log those to a tmp file while running your script to check if
> there is any significant difference..
>
> > Le dim. 16 sept. 2018 17:02, Romain Beauxis
> a écrit :
> >>
> >> Hi,
> >>
> >> Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt
> >> a écrit :
> >> > I made a little script in python to fetch my files from my nextcloud
> share.
> >> > I add a add_protocol function to fetch them in liquidsoap.
> >> > So far it doesn't work in liquidsoap but the command works in a shell.
> >> >
> >> > Below the code made for testing purpose:
> >> >
> >> > def nextcloud(~rlog,~maxtime,arg) =
> >> > extname = file.extension(dir_sep="/",arg)
> >> > [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
> '#{arg}' $(output)")]
> >> > end
> >> > add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
> syntax="nc://uri")
> >> >
> >> > default = single("default/single.mp3")
> >> > genre1 = playlist("nc://genre1/playlist1.txt")
> >> > day = genre1
> >> > night = genre1
> >> > radio = fallback([ request.queue(id="request"),
> >> > switch([({ 6h-22h }, day),
> >> > ({ 22h-6h }, night)]),
> >> > default])
> >> > output.alsa(radio)
> >> >
> >> > Content of the playlist1.txt file:
> >> > nc://genre1/file1.mp3
> >> > nc://genre1/file2.mp3
> >> >
> >> > The log file:
> >> >
> >> > 2018/09/16 16:41:08 [playlist1(dot)txt:3] Loading playlist...
> >> > 2018/09/16 16:41:28 [protocol.process:3] Failed to execute
> /usr/bin/python3 /work/get_file.py '//genre1/playlist1.txt'
> "/tmp/liq-process3ceb08..txt": ("timeout","19.9620351791")
> >> > 2018/09/16 16:41:28 [playlist1(dot)txt:2] Failed when resolving
> playlist URI "nc://genre1/playlist1.txt"!
> >> > 2018/09/16 16:41:28 [playlist1(dot)txt:3] Successfully loaded a
> playlist of 0 tracks.
> >>
> >> Your script looks really good, sounds like a nice feature.
> >>
> >> It seems that the issue is a timeout: the script takes more than the
> default timeout of 20 sec. You may want to increase by setting a different
> timeout parameter in your playlist:
> >>
> >> genre1 = playlist(timeout=, "nc://genre1/playlist1.txt")
> >>
> >> Hope this helps!
> >>
> >>
> >> Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
> >>>
> >>> Hi,
> >>>
> >>> I made a little script in python to fetch my files from my nextcloud
> share.
> >>> I add a add_protocol function to fetch them in liquidsoap.
> >>> So far it doesn't work in liquidsoap but the command works in a shell.
> >>>
> >>> Below the code made for testing purpose:
> >>>
> >>> def nextcloud(~rlog,~maxtime,arg) =
> >>> extname = file.extension(dir_sep="/",arg)
> >>> [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
> '#{arg}' $(output)")]
> >>> end
> >>> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
> syntax="nc://uri")
> >>>
> >>> default = single("default/single.mp3")
> >>> genre1 = playlist("nc://genre1/playlist1.txt")
> >>> day = genre1
> >>> night = genre1
> >>> radio = fallback([ request.queue(id="request"),
> >>> switch([({ 6h-22h }, day),
> >>> ({
Re: [Savonet-users] add_protocol issue
Le dim. 16 sept. 2018 à 10:15, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
> Already tested it with 30 and 60 seconds. The command took under 10
seconds in a shell so don't know where is my mystake.
> If i check the file i got un /tmp the content is OK !
Ok. Your next step is to check on environment variables. Does your script
rely on some environment variables or specific user to run correctly?
The essential difference between running the script in a shell and inside
the liquidsoap process are the user running it and the environment
variables passed to it.
Inside liquidsoap, user will be whatever it run as and environment variable
should be inherited from the parent liquidsoap process. You should be able
to log those to a tmp file while running your script to check if there is
any significant difference..
> Le dim. 16 sept. 2018 17:02, Romain Beauxis a
écrit :
>>
>> Hi,
>>
>> Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt
>> a écrit :
>> > I made a little script in python to fetch my files from my nextcloud
share.
>> > I add a add_protocol function to fetch them in liquidsoap.
>> > So far it doesn't work in liquidsoap but the command works in a shell.
>> >
>> > Below the code made for testing purpose:
>> >
>> > def nextcloud(~rlog,~maxtime,arg) =
>> > extname = file.extension(dir_sep="/",arg)
>> > [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
'#{arg}' $(output)")]
>> > end
>> > add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
syntax="nc://uri")
>> >
>> > default = single("default/single.mp3")
>> > genre1 = playlist("nc://genre1/playlist1.txt")
>> > day = genre1
>> > night = genre1
>> > radio = fallback([ request.queue(id="request"),
>> > switch([({ 6h-22h }, day),
>> > ({ 22h-6h }, night)]),
>> > default])
>> > output.alsa(radio)
>> >
>> > Content of the playlist1.txt file:
>> > nc://genre1/file1.mp3
>> > nc://genre1/file2.mp3
>> >
>> > The log file:
>> >
>> > 2018/09/16 16:41:08 [playlist1(dot)txt:3] Loading playlist...
>> > 2018/09/16 16:41:28 [protocol.process:3] Failed to execute
/usr/bin/python3 /work/get_file.py '//genre1/playlist1.txt'
"/tmp/liq-process3ceb08..txt": ("timeout","19.9620351791")
>> > 2018/09/16 16:41:28 [playlist1(dot)txt:2] Failed when resolving
playlist URI "nc://genre1/playlist1.txt"!
>> > 2018/09/16 16:41:28 [playlist1(dot)txt:3] Successfully loaded a
playlist of 0 tracks.
>>
>> Your script looks really good, sounds like a nice feature.
>>
>> It seems that the issue is a timeout: the script takes more than the
default timeout of 20 sec. You may want to increase by setting a different
timeout parameter in your playlist:
>>
>> genre1 = playlist(timeout=, "nc://genre1/playlist1.txt")
>>
>> Hope this helps!
>>
>>
>> Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
>>>
>>> Hi,
>>>
>>> I made a little script in python to fetch my files from my nextcloud
share.
>>> I add a add_protocol function to fetch them in liquidsoap.
>>> So far it doesn't work in liquidsoap but the command works in a shell.
>>>
>>> Below the code made for testing purpose:
>>>
>>> def nextcloud(~rlog,~maxtime,arg) =
>>> extname = file.extension(dir_sep="/",arg)
>>> [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
'#{arg}' $(output)")]
>>> end
>>> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
syntax="nc://uri")
>>>
>>> default = single("default/single.mp3")
>>> genre1 = playlist("nc://genre1/playlist1.txt")
>>> day = genre1
>>> night = genre1
>>> radio = fallback([ request.queue(id="request"),
>>> switch([({ 6h-22h }, day),
>>> ({ 22h-6h }, night)]),
>>> default])
>>> output.alsa(radio)
>>>
>>> Content of the playlist1.txt file:
>>> nc://genre1/file1.mp3
>>> nc://genre1/file2.mp3
>>>
>>> The log file:
>>>
>>> 2018/09/16 16:41:08 [playlist1(dot)txt:3] Loading playlist...
>>> 2018/09/16 16:41:28 [protocol.process:3] Failed to execute
/usr/bin/python3 /work/get_file.py '//genre1/playlist1.txt'
"/tmp/liq-process3ceb08..txt": ("timeout","19.9620351791")
>>> 2018/09/16 16:41:28 [playlist1(dot)txt:2] Failed when resolving
playlist URI "nc://genre1/playlist1.txt"!
>>> 2018/09/16 16:41:28 [playlist1(dot)txt:3] Successfully loaded a
playlist of 0 tracks.
>>>
>>> ___
>>> 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
>
> ___
> Savonet-users mailing list
> Savonet-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] add_protocol issue
Hi,
Already tested it with 30 and 60 seconds. The command took under 10 seconds
in a shell so don't know where is my mystake.
If i check the file i got un /tmp the content is OK !
Le dim. 16 sept. 2018 17:02, Romain Beauxis a
écrit :
> Hi,
>
> Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt
> a écrit :
> > I made a little script in python to fetch my files from my nextcloud
> share.
> > I add a add_protocol function to fetch them in liquidsoap.
> > So far it doesn't work in liquidsoap but the command works in a shell.
> >
> > Below the code made for testing purpose:
> >
> > def nextcloud(~rlog,~maxtime,arg) =
> > extname = file.extension(dir_sep="/",arg)
> > [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
> '#{arg}' $(output)")]
> > end
> > add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
> syntax="nc://uri")
> >
> > default = single("default/single.mp3")
> > genre1 = playlist("nc://genre1/playlist1.txt")
> > day = genre1
> > night = genre1
> > radio = fallback([ request.queue(id="request"),
> > switch([({ 6h-22h }, day),
> > ({ 22h-6h }, night)]),
> > default])
> > output.alsa(radio)
> >
> > Content of the playlist1.txt file:
> > nc://genre1/file1.mp3
> > nc://genre1/file2.mp3
> >
> > The log file:
> >
> > 2018/09/16 16:41:08 [playlist1(dot)txt:3] Loading playlist...
> > 2018/09/16 16:41:28 [protocol.process:3] Failed to execute
> /usr/bin/python3 /work/get_file.py '//genre1/playlist1.txt'
> "/tmp/liq-process3ceb08..txt": ("timeout","19.9620351791")
> > 2018/09/16 16:41:28 [playlist1(dot)txt:2] Failed when resolving playlist
> URI "nc://genre1/playlist1.txt"!
> > 2018/09/16 16:41:28 [playlist1(dot)txt:3] Successfully loaded a playlist
> of 0 tracks.
>
> Your script looks really good, sounds like a nice feature.
>
> It seems that the issue is a timeout: the script takes more than the
> default timeout of 20 sec. You may want to increase by setting a different
> timeout parameter in your playlist:
>
> genre1 = playlist(timeout=, "nc://genre1/playlist1.txt")
>
> Hope this helps!
>
>
> Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt <
> sebastien.dagnico...@gmail.com> a écrit :
>
>> Hi,
>>
>> I made a little script in python to fetch my files from my nextcloud
>> share.
>> I add a add_protocol function to fetch them in liquidsoap.
>> So far it doesn't work in liquidsoap but the command works in a shell.
>>
>> Below the code made for testing purpose:
>>
>> def nextcloud(~rlog,~maxtime,arg) =
>> extname = file.extension(dir_sep="/",arg)
>> [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
>> '#{arg}' $(output)")]
>> end
>> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
>> syntax="nc://uri")
>>
>> default = single("default/single.mp3")
>> genre1 = playlist("nc://genre1/playlist1.txt")
>> day = genre1
>> night = genre1
>> radio = fallback([ request.queue(id="request"),
>> switch([({ 6h-22h }, day),
>> ({ 22h-6h }, night)]),
>> default])
>> output.alsa(radio)
>>
>> Content of the playlist1.txt file:
>> nc://genre1/file1.mp3
>> nc://genre1/file2.mp3
>>
>> The log file:
>>
>> 2018/09/16 16:41:08 [playlist1(dot)txt:3] Loading playlist...
>> 2018/09/16 16:41:28 [protocol.process:3] Failed to execute
>> /usr/bin/python3 /work/get_file.py '//genre1/playlist1.txt'
>> "/tmp/liq-process3ceb08..txt": ("timeout","19.9620351791")
>> 2018/09/16 16:41:28 [playlist1(dot)txt:2] Failed when resolving playlist
>> URI "nc://genre1/playlist1.txt"!
>> 2018/09/16 16:41:28 [playlist1(dot)txt:3] Successfully loaded a playlist
>> of 0 tracks.
>>
>> ___
>> 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
>
___
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] add_protocol issue
Hi,
Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt
a écrit :
> I made a little script in python to fetch my files from my nextcloud
share.
> I add a add_protocol function to fetch them in liquidsoap.
> So far it doesn't work in liquidsoap but the command works in a shell.
>
> Below the code made for testing purpose:
>
> def nextcloud(~rlog,~maxtime,arg) =
> extname = file.extension(dir_sep="/",arg)
> [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
'#{arg}' $(output)")]
> end
> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
syntax="nc://uri")
>
> default = single("default/single.mp3")
> genre1 = playlist("nc://genre1/playlist1.txt")
> day = genre1
> night = genre1
> radio = fallback([ request.queue(id="request"),
> switch([({ 6h-22h }, day),
> ({ 22h-6h }, night)]),
> default])
> output.alsa(radio)
>
> Content of the playlist1.txt file:
> nc://genre1/file1.mp3
> nc://genre1/file2.mp3
>
> The log file:
>
> 2018/09/16 16:41:08 [playlist1(dot)txt:3] Loading playlist...
> 2018/09/16 16:41:28 [protocol.process:3] Failed to execute
/usr/bin/python3 /work/get_file.py '//genre1/playlist1.txt'
"/tmp/liq-process3ceb08..txt": ("timeout","19.9620351791")
> 2018/09/16 16:41:28 [playlist1(dot)txt:2] Failed when resolving playlist
URI "nc://genre1/playlist1.txt"!
> 2018/09/16 16:41:28 [playlist1(dot)txt:3] Successfully loaded a playlist
of 0 tracks.
Your script looks really good, sounds like a nice feature.
It seems that the issue is a timeout: the script takes more than the
default timeout of 20 sec. You may want to increase by setting a different
timeout parameter in your playlist:
genre1 = playlist(timeout=, "nc://genre1/playlist1.txt")
Hope this helps!
Le dim. 16 sept. 2018 à 09:55, sébastien dagnicourt <
sebastien.dagnico...@gmail.com> a écrit :
> Hi,
>
> I made a little script in python to fetch my files from my nextcloud share.
> I add a add_protocol function to fetch them in liquidsoap.
> So far it doesn't work in liquidsoap but the command works in a shell.
>
> Below the code made for testing purpose:
>
> def nextcloud(~rlog,~maxtime,arg) =
> extname = file.extension(dir_sep="/",arg)
> [process_uri(extname=extname,"/usr/bin/python3 /work/get_file.py
> '#{arg}' $(output)")]
> end
> add_protocol("nc",nextcloud,doc="Fetch files from nextcloud",
> syntax="nc://uri")
>
> default = single("default/single.mp3")
> genre1 = playlist("nc://genre1/playlist1.txt")
> day = genre1
> night = genre1
> radio = fallback([ request.queue(id="request"),
> switch([({ 6h-22h }, day),
> ({ 22h-6h }, night)]),
> default])
> output.alsa(radio)
>
> Content of the playlist1.txt file:
> nc://genre1/file1.mp3
> nc://genre1/file2.mp3
>
> The log file:
>
> 2018/09/16 16:41:08 [playlist1(dot)txt:3] Loading playlist...
> 2018/09/16 16:41:28 [protocol.process:3] Failed to execute
> /usr/bin/python3 /work/get_file.py '//genre1/playlist1.txt'
> "/tmp/liq-process3ceb08..txt": ("timeout","19.9620351791")
> 2018/09/16 16:41:28 [playlist1(dot)txt:2] Failed when resolving playlist
> URI "nc://genre1/playlist1.txt"!
> 2018/09/16 16:41:28 [playlist1(dot)txt:3] Successfully loaded a playlist
> of 0 tracks.
>
> ___
> 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
