crkm wrote:
> Hi Philippe
> Thanks again
> Here's what I did to create the attached files.
> Deleted config.xml
> from cmd window: squeeze2upnp -i config.xml -f 21Mar
> let program complete
> zipped config.xml and 21Mar into 1st Run zip file
> Edited config.xml to change <buffer_dir> and change to flac
> from cmd window: squeeze2upnp -f 21Mar2
> Started playing to Foobar2000 from LMS
> Started playing to CA from LMS (Foobar crashes)
> Stopped playing to CA from LMS
> from cmd window: exit
> zipped config.xml and 21Mar2 into 2nd run zip file
>
> Best regards
> crkm
oh ... one interesting chicken & egg problem: because of the problem
with the <buffer_dir> default parameter, the creation of the config.xml
file does not work properly (no LMS device can be created). Can you make
sure you run squeeze2upnp in a directory where you have rw access ? You
do not need to run it in admin mode. This really (really) should work
with "." as the buffer dir if you start it from an accessible directory.
Otherwise, you can re-run it with -i option after you have set the
<buffer_dir> to somethign accessible. Also, I've pushed on GitHub, in
the dev directory, a version that, when launched with -i, will records
ALL the discovered upnp devices and will NOT try to create a LMS
instance.
Foobar stops because of lack of audio data. It seems that what you send
to foobar is coming from a stream and there is a timeout happening into
sq2u. The timeout happens when the other play command occurs, because
creation of the other temp file takes too much time. This would probably
not happen if you where playing a file, not a stream. The problem with
streams is that there is always very few data to be buffered. But most
likely, your <buffer_dir> is on a very slow peripheral (like a network
drive) that can cause buffering problems, stream or not. In this log
Code:
--------------------
[08:32:14.697] sq_read:677 [0048773C]: read 1048576 (r:200704 w:62)
[08:32:14.747] sq_read:677 [0048773C]: read 1048576 (r:98304 w:99)
[08:32:16.303] sq_read:677 [0048773C]: read 1048576 (r:69632 w:100)
[08:32:18.779] sq_read:677 [0048773C]: read 1048576 (r:253952 w:74)
[08:32:18.829] sq_read:677 [0048773C]: read 1048576 (r:110592 w:99)
[08:32:22.842] sq_read:677 [0048773C]: read 1048576 (r:8192 w:65)
--------------------
The w:xxx value should almost never be below <max_read_wait> - 5. The
meaning of this is the amount of time sq2u had to wait to have data
available in the buffer to be sent to the upnp player, calculated this
way : (<max_read_wait> - w:xxx)*50ms. For example, with a value of 62,
it means that sq2u waited (100-62)*50ms = 1.9s before getting data !
Anywa, forget the technical explanations, you can do two things:
1/ if the buffer directory G:\garmin is a slow access peripheral (a
network drive for example - or something where file creation can be
slow), change it to a local drive and all issue will be solved
2/ change the parameter <max_read_wait> to 200 or a bit more. I really
(really) do not recommend using this solution, but you can try
LMS 7.7.2 - 5 radio, 3 Boom, 4 Duet, 1 Touch, 1 SB2. Sonos 2xPLAY:1,
PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBMC, Foobar2000, XBoxOne
(sort of)
------------------------------------------------------------------------
philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261
View this thread: http://forums.slimdevices.com/showthread.php?t=102496
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
