philippe_44 wrote: > 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) so you do not > see the detected upnp renderers on your network. 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 a second time with -i option after you have > set the <buffer_dir> to something 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, so no failure can happen at this 1st stage > > 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 ! > > Anyway, 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 issues 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
Hi Philippe Thanks yet again. My G: drive is the windows/boot drive (i.e. local) mounted in the PC and is an SSD. I moved everything to a new subdirectory G:\s2u and repeated the tests. At least this fixed the default <buffer_dir> problem (see 1st zip file) However, I'm still getting the low w:xxx values when playing the radio streams, see 2nd zip file. This problem goes away when playing a music file situated on another local drive, 3rd zip file. Thanks again for your help, the set-up does 90% of what I need to do. Best crkm ------------------------------------------------------------------------ crkm's Profile: http://forums.slimdevices.com/member.php?userid=64078 View this thread: http://forums.slimdevices.com/showthread.php?t=102496 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
