Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
pupvogel wrote: > Maybe it's worth mentioning: > I tried downloading the whole track (using dlmixcloud.com) to check if > it plays through when NOT streaming. It does. Just remembered - watchdog timer is only enabled for remote streaming. The watchdog timer was implemented because when remote source reset the link - transcoding chain would shutdown but often leaving zombie processes. For some users with a favorite station played often - this resulted in the regularly need to reboot the PC. Need to check whether watchdog mechanism is "faulty" now that buffered (i.e. saved in a temp file) remote streaming has been implemented (e.g. whole source is downloaded into LMS within seconds of playing starting and prorbably connection closed). Intuitively this should not be the case as player consumes audio at rate of playing and so audio data should be flowing constantly through socketwrapper as long as there is data to be played regardless of source. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
There is a subtle difference between playing same track on same player between a Ubuntu based LMS and a Windows. It looks like there is a slight difference in processing the MP4 file header. Ubuntu Logitech Media Server Version: 8.3.0 "nightly" Code: [22-04-15 19:55:04.2969] Slim::Player::StreamingController::_setStreamingState (2387) new streaming state TRACKWAIT [22-04-15 19:55:04.2971] Plugins::MixCloud::ProtocolHandler::getMetadataFor (223) Getting track details for mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/undef [22-04-15 19:55:04.2980] Slim::Player::StreamingController::_playersMessage (796) Getting stream info...: mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 19:55:04.2983] Slim::Player::Song::getNextSong (222) mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 19:55:04.2984] Slim::Player::Song::getNextSong (244) scanning URL mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 19:55:04.2985] Slim::Player::Song::getNextSong (222) mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 19:55:04.2987] Plugins::MixCloud::ProtocolHandler::_fetchTrackExtra (171) Fetching complement with downloader mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ https://www.mixcloud.com/ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 19:55:04.3414] Slim::Player::TranscodingHelper::getConvertCommand2 (490) Error: Didn't find any command matches for type: mp4 [22-04-15 19:55:07.7291] Plugins::MixCloud::ProtocolHandler::__ANON__ (193) Got play URL https://stream11.mixcloud.com/secure/c/m4a/64/7/2/a/7/4486-cf19-4fe5-83d1-a98ea70cef37.m4a?sig=wcVlYHLxDScCMcXBJopQpw for mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ from download [22-04-15 19:55:08.0451] Slim::Formats::Movie::parseStream (236) found audio offset with stco 325972 [22-04-15 19:55:08.0488] Slim::Player::StreamingController::_nextTrackReady (744) 00:04:20:16:07:0e: nextTrack will be index 0 [22-04-15 19:55:08.0492] Slim::Player::StreamingController::_Stream (1211) Song queue is now 0 [22-04-15 19:55:08.0495] Slim::Player::StreamingController::_Stream (1214) 00:04:20:16:07:0e: preparing to stream song index 0 [22-04-15 19:55:08.0498] Slim::Player::Song::open (362) mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 19:55:08.0502] Slim::Player::Song::open (394) seek=false time=0 canSeek=0SEEK_ERROR_TYPE_NOT_SUPPORTEDmp4 [22-04-15 19:55:08.0509] Slim::Player::TranscodingHelper::getConvertCommand2 (490) Error: Didn't find any command matches for type: mp4 [22-04-15 19:55:08.0516] Slim::Player::TranscodingHelper::getConvertCommand2 (493) Matched: aac->flc via: [faad] -q -w -f 1 $FILE$ | [flac] -cs --totally-silent --compression-level-0 --ignore-chunk-sizes - [22-04-15 19:55:08.0518] Slim::Player::Song::open (424) Transcoder: streamMode=I, streamformat=flc [22-04-15 19:55:08.0521] Slim::Player::Song::open (480) Opening stream (no direct streaming) using Plugins::MixCloud::ProtocolHandler [mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/] [22-04-15 19:55:08.0522] Plugins::MixCloud::ProtocolHandler::new (65) Remote streaming Mixcloud track: https://stream11.mixcloud.com/secure/c/m4a/64/7/2/a/7/4486-cf19-4fe5-83d1-a98ea70cef37.m4a?sig=wcVlYHLxDScCMcXBJopQpw [22-04-15 19:55:08.0523] Plugins::MixCloud::ProtocolHandler::new (75) Using Slim::Player::Protocols::HTTPS; [22-04-15 19:55:08.0524] Slim::Player::Protocols::HTTPS::new (38) Opening connection to https://stream11.mixcloud.com/secure/c/m4a/64/7/2/a/7/4486-cf19-4fe5-83d1-a98ea70cef37.m4a?sig=wcVlYHLxDScCMcXBJopQpw: [stream11.mixcloud.com on port 443 with path /secure/c/m4a/64/7/2/a/7/4486-cf19-4fe5-83d1-a98ea70cef37.m4a?sig=wcVlYHLxDScCMcXBJopQpw with timeout 15] [22-04-15 19:55:08.2034] Slim::Formats::Movie::getInitialAudioBlock (181) Reading initial audio block: length 325972 [22-04-15 19:55:08.2038] Slim::Player::Protocols::HTTP::request (166) building new header [22-04-15 19:55:08.2046] Slim::Formats::RemoteStream::request (144) Request: GET /secure/c/m4a/64/7/2/a/7/4486-cf19-4fe5-83d1-a98ea70cef37.m4a?sig=wcVlYHLxDScCMcXBJopQpw HTTP/1.0 Windows Logitech Media Server Version: v8.3.0, 1649774106, Tue Apr 12 21:54:57 WEDT 2022 Code: [22-04-15 20:15:32.3136] Slim::Player::StreamingController::_setStreamingState (2387) new streaming state TRACKWAIT [22-04-15 20:15:32.3139] Slim::Player::StreamingController::_playersMessage (796) Getting stream info...: mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 20:15:32.3141] Slim::Player::Song::getNextSong (222) mixcloud://ibizasonica/jacks-house-radio-show-by-clara-da-costa/ [22-04-15 20:15:32.3142] Slim::Player::Song::getNextSong (244) scanning URL
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
pupvogel wrote: > Maybe it's worth mentioning: > I tried downloading the whole track (using dlmixcloud.com) to check if > it plays through when NOT streaming. It does. I did that yesterday on Linux just to check mp4/faad handling in case there was something unusual. As playing from a file shows that transcoded stream to player does not trigger Watchdog. I feel the problem is to do with input streaming which is being buffered and then passed through transcoding chain before being streamed to player (even though player on same system as server, TCP networking is used). Often in these cases input stream gets reset if player is playing audio and not asking for data, which is why HTTP "persistent" buffering is needed. So there may be an unusual set of read/writes. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Maybe it's worth mentioning: I tried downloading the whole track (using dlmixcloud.com) to check if it plays through when NOT streaming. It does. pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > Prefer native checked just means it plays without transcoding as you > reported yesterday. > On my system it played OK - I had to uncheck "native" and disable > "mp4->AAC" to get squeezelite on Win to fail > > This is what I mean that your setup (i.e. Win1,, network, secxurit s/w > etc.) is in some way "unusual". It really plays through on your Win-machine..? Weird... I can confirm the new Mixcloud-release doesn't help with this, unfortunately. pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
pupvogel wrote: > @bpa > But even with "prefer native" checked (under Settings->Advanced->File > Types), the Digweed-track will stop before 3min00 in Squeezelite-X. Prefer native checked just means it plays without transcoding as you reported yesterday. On my system it played OK - I had to uncheck "native" and disable "mp4->AAC" to get squeezelite on Win to fail This is what I mean that your setup (i.e. Win1,, network, secxurit s/w etc.) is in some way "unusual". bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > No - standard installation prefers "native" and no transcoding (i.e. > least processing - audio data from source gets delivered to player > unchanged), so all settings enabled - I had to disable them and force > transcoding. > > With forcing transcoding with Squeezelite - "Clara de Costa" on my i7 > Win10 system stops in less than 1min. @bpa But even with "prefer native" checked (under Settings->Advanced->File Types), the Digweed-track will stop before 3min00 in Squeezelite-X. pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
There was an 'update to the mixcloud plugin this morning at least in the dev channel' (https://forums.slimdevices.com/showthread.php?88286-Mixcloud-plugin=1052503=1#post1052503). Might be worth checking if it fixes the problem. Ralphy *1*-Touch, *5*-Classics, *3*-Booms, *2*-UE Radio 'Squeezebox client builds' (https://sourceforge.net/projects/lmsclients/files/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
pupvogel wrote:
> Is this how squeezelite-x is set-up when I install it ? Because I never
> changed any settings for it...and the "Digweed Denney"-example stops at
> about the same time on both hardware players and the Squeezelite.
> Other tracks are not that consistent, so I would recommend using that
> one for testing.
>
> For example the other track I mentioned earlier ("Clara da Costa")
> sometimes plays up to ten minutes before stopping.
>
> My Squeezelite is also v1.9.9-1401.
No - standard installation prefers "native" and no transcoding (i.e.
least processing - audio data from source gets delivered to player
unchanged), so all settings enabled - I had to disable them and force
transcoding.
With forcing transcoding with Squeezelite - "Clara de Costa" on my i7
Win10 system stops in less than 1min.
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=116078
___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote:
> squeezelite on Win also fails if native MP4/AAC is disabled (and prfer
> native decode check box off) and so transcoding is required.
> It means a simple single system test setup can be used to test.
Is this how squeezelite-x is set-up when I install it ? Because I never
changed any settings for it...and the "Digweed Denney"-example stops at
about the same time on both hardware players and the Squeezelite.
Other tracks are not that consistent, so I would recommend using that
one for testing.
For example the other track I mentioned earlier ("Clara da Costa")
sometimes plays up to ten minutes before stopping.
My Squeezelite is also v1.9.9-1401.
pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152
View this thread: http://forums.slimdevices.com/showthread.php?t=116078
___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
squeezelite on Win also fails if native MP4/AAC is disabled (and prfer native decode check box off) and so transcoding is required. It means a simple single system test setup can be used to test. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Managed to setup a win 11 system and I got a similar issue with a Boom but no problem with Radio or a squeezlite 1.9.9-1401 on the Windows system. So there could be an issue with mixcloud buffering and socketwrapper. It is possible you have a second similar problem which is manifesting on the Squeezelite-x or perhaps the same issue but very rarely appears on non old SB players but something on your setup has triggered it - in this case Mixcloud buffering would be areas of interest. What version of squeezelite is running in Squeezelite-X ? I'll see if I can add log statements to Mixcloud to get better insight. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
pupvogel wrote: > Err, yes you are right, now that really explains why I didn't get a > socketwrapper-log when streaming to Squeezelite-X... 8-p > > Also (sorry, just remembered), in the other thread, "chieftobitobsn" > remarked that he has the same issue on a raspi3/debian-system, so it > cannot be Windows only. The "end of file" usually means the source has stopped after 2,544,246 AAC bytes. The stream is about 60,281,586 long (includes some MPEG4 headers) Code: [22-04-14 17:37:38.] Slim::Player::StreamingController::_eventAction (270) 18:c0:4d:e9:61:7b: Started in BUFFERING-STREAMING -> Slim::Player::StreamingController::_Playing [22-04-14 17:37:38.6667] Slim::Player::StreamingController::_setPlayingState (2378) new playing state PLAYING [22-04-14 17:37:38.6667] Slim::Player::StreamingController::_Playing (368) Song 0 has now started playing [22-04-14 17:37:38.6670] Slim::Player::StreamingController::_Playing (397) Song queue is now 0 [22-04-14 17:37:38.6671] Slim::Player::StreamingController::_eventAction (302) 18:c0:4d:e9:61:7b: Started - new state PLAYING-STREAMING [22-04-14 17:37:38.6672] Slim::Player::StreamingController::_eventAction (270) 18:c0:4d:e9:61:7b: StatusHeartbeat in PLAYING-STREAMING -> Slim::Player::StreamingController::_CheckSync [22-04-14 17:37:38.8039] Slim::Player::Source::_readNextChunk (345) Got EINTR, will try again later. [22-04-14 17:37:39.2305] Slim::Player::Source::_readNextChunk (345) Got EINTR, will try again later. [22-04-14 17:37:39.6462] Slim::Player::Source::_readNextChunk (345) Got EINTR, will try again later. [22-04-14 17:37:40.0649] Slim::Player::Source::_readNextChunk (355) Read to end of file or pipe [22-04-14 17:37:40.0653] Slim::Player::Source::_readNextChunk (378) end of file or error on socket, song pos: 2544246 [22-04-14 17:37:40.0656] Slim::Player::Source::_readNextChunk (383) 18:c0:4d:e9:61:7b mark end of stream bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Err, yes you are right, now that really explains why I didn't get a socketwrapper-log when streaming to Squeezelite-X... 8-p Also (sorry, just remembered), in the other thread, "chieftobitobsn" remarked that he has the same issue on a raspi3/debian-system, so it cannot be Windows only. +---+ |Filename: server.log | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=37703| +---+ pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
pupvogel wrote: > Here is another log-combo, this time with Mixcloud-logging set to > debug. > Doesn't add too much info, though... Yes - looks like Mixcloud has no relevant logging and would need to be modified to tge the data. Bugs in socketwrapper usually result in loss of data at start or the very end. When a stream stops mid stream - the problem can be buffering and sizes of buffers in player and network timeouts in the source. socketwrapper was written many many years ago when to overcome a Perl/Windows shortcoming. Processors were single core and player had small buffer and streams were only slow. LMS could only relay small amounts of data. Many changes since then. Processors have multi core so race conditions may occur. Since Win 10, a bit of Windows internal scheduling has changed - so windows doesn't quite behave as it used to. To cope with network reset when streaming large podcasts (i.e. multimegabyte files) which didn;t like keeping networkj connection open while player played audio in realtime - LMS now has various buffering mechanisms. Some players (e.g. squeezelite) can now very large internal buffers which means huge demand for audio data at beginning and then nothing for the last section. Squeezelite can also play more formats so transcode doesn't happen so offering squeezelite players as a baseline example is not applicable. My first inclination is to understand how data is being buffered in this stream - from mixcloud through LMS and transcode chain into a player. However clarification is needed. You seem to indicate the problem as happens with Squeezlite-X. If the problem happens with Squeezelite - squeezelite can play AAC native (as file is AAC codec in MPEG-4 format) so there should be no transcoding and no socketwrapper. Can you get a server.log of player.source when playing to Squeezelite-X bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Here is another log-combo, this time with Mixcloud-logging set to debug. Doesn't add too much info, though... +---+ |Filename: Logs.zip | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=37701| +---+ pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
I think a network issue can be ruled out, as the problem is really very consistent, even on the Squeezelite-X-player on the server itself. The hardware players I have are these: Code: Player Model: Squeezebox Boom Player Type: boom Firmware: 57 Player IP Address: 192.168.13.140 Player MAC Address: 00:04:20:1f:84:2c Player Model: Squeezebox Classic Player Type: squeezebox2 Firmware: 137 Player IP Address: 192.168.13.104 Player MAC Address: 00:04:20:07:4e:3b Isn't it strange that really VERY shortly after the player switches from "BUFFERING-STREAMING" to "PLAYING-STREAMING" it reports "EOF on source stream", even though the SocketWrapper is still working at that time..? Code: [22-04-14 15:26:56.6244] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer [22-04-14 15:26:56.6245] Slim::Player::Pipeline::sysread (310) Wrote 17113 bytes to pipeline writer [22-04-14 15:26:56.6245] Slim::Player::Pipeline::sysread (281) Pipeline doesn't have pending bytes - trying to get some from source [22-04-14 15:26:56.6405] Slim::Player::StreamingController::playerTrackStarted (2201) 00:04:20:07:4e:3b [22-04-14 15:26:56.6406] Slim::Player::StreamingController::_eventAction (270) 00:04:20:07:4e:3b: Started in BUFFERING-STREAMING -> Slim::Player::StreamingController::_Playing [22-04-14 15:26:56.6406] Slim::Player::StreamingController::_setPlayingState (2378) new playing state PLAYING [22-04-14 15:26:56.6407] Slim::Player::StreamingController::_Playing (368) Song 0 has now started playing [22-04-14 15:26:56.6409] Slim::Player::StreamingController::_Playing (397) Song queue is now 0 [22-04-14 15:26:56.6411] Slim::Player::StreamingController::_eventAction (302) 00:04:20:07:4e:3b: Started - new state PLAYING-STREAMING [22-04-14 15:26:56.6552] Slim::Player::Pipeline::sysread (281) Pipeline doesn't have pending bytes - trying to get some from source [22-04-14 15:26:56.6556] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer [22-04-14 15:26:56.6557] Slim::Player::Pipeline::sysread (310) Wrote 16919 bytes to pipeline writer [22-04-14 15:26:56.6557] Slim::Player::Pipeline::sysread (281) Pipeline doesn't have pending bytes - trying to get some from source [22-04-14 15:26:56.6561] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer [22-04-14 15:26:56.6561] Slim::Player::Pipeline::sysread (310) Wrote 17012 bytes to pipeline writer [22-04-14 15:26:56.6562] Slim::Player::Pipeline::sysread (281) Pipeline doesn't have pending bytes - trying to get some from source [22-04-14 15:26:56.6564] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer [22-04-14 15:26:56.6565] Slim::Player::Pipeline::sysread (310) Wrote 11512 bytes to pipeline writer [22-04-14 15:26:56.6566] Slim::Player::Pipeline::sysread (281) Pipeline doesn't have pending bytes - trying to get some from source [22-04-14 15:26:56.6566] Slim::Player::Pipeline::sysread (288) EOF on source stream [22-04-14 15:26:56.7041] Slim::Player::StreamingController::_eventAction (270) 00:04:20:07:4e:3b: StatusHeartbeat in PLAYING-STREAMING -> Slim::Player::StreamingController::_CheckSync [22-04-14 15:26:57.7075] Slim::Player::StreamingController::_eventAction (270) 00:04:20:07:4e:3b: StatusHeartbeat in PLAYING-STREAMING -> Slim::Player::StreamingController::_CheckSync [22-04-14 15:26:58.7057] Slim::Player::StreamingController::_eventAction (270) 00:04:20:07:4e:3b: StatusHeartbeat in PLAYING-STREAMING -> Slim::Player::StreamingController::_CheckSync Exactly at that time, there is a weird 2 second gap in the socketwrapper-log: Code: SW: 2022-04-14 15:26:56.634 MoveDataThreadProc for step 3 got 8192 bytes, about to write data. SW: 2022-04-14 15:26:56.635 MoveDataThreadProc for step 3 about to call ReadFile. SW: 2022-04-14 15:26:56.635 MoveDataThreadProc for step 3 got 8192 bytes, about to write data. SW: 2022-04-14 15:26:58.745 MoveDataThreadProc for step 3 about to call ReadFile. SW: 2022-04-14 15:26:58.745 MoveDataThreadProc for step 3 got 8192 bytes, about to write data. SW: 2022-04-14 15:26:58.747 MoveDataThreadProc for step 3 about to call ReadFile. pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
pupvogel wrote: > Ok, found the problem...here's both a server.log including timestamps > and the corresponding socketwrapperdebug.log Need more on system details. What sort of player et.c Socketwrapper is like the old firebucket chain - socketwrapper make sure data is passed from one process to the next in the transcode chain - multiple threads each one does the same thing: Wait for data, Read-data, Write data - repeat Looking at timing - socketwrapper is passing data up to 15:27:14.801 - then suddenly no more data to read/write (i.e. player has stopped and/or source has stopped - possible network issue). Socketwrapper waits for x secs and since nothing has moved, watchdig expires - shutdown at 15:27:26 (i.e. 12 secs ) Code: SW: 2022-04-14 15:27:14.800 MoveDataThreadProc for step 3 about to call ReadFile. SW: 2022-04-14 15:27:14.801 MoveDataThreadProc for step 3 got 8192 bytes, about to write data. SW: 2022-04-14 15:27:26.070 Watchdog expired - Thread for step 3 stalled. SW: 2022-04-14 15:27:26.071 Tidying up SW: 2022-04-14 15:27:26.073 Watchdog expired SW: 2022-04-14 15:27:28.076 Tidying up - Thread for step 0 hasn't died. SW: 2022-04-14 15:27:28.077 Thread for step 0 streamed145 blocks totalling 00121FB7 (1187767) bytes SW: 2022-04-14 15:27:28.078 Waiting for process step 1 to terminate LMS logs - sysread is reading data from transcoded chain and it shown data stop at 15:26:56 - about a minute before socketwrapper has problems. Code: [22-04-14 15:26:56.0374] Slim::Player::Pipeline::acceptReader (202) Pipeline reader connected [22-04-14 15:26:56.1307] Slim::Player::Player::_buffering (1154) Buffering... 0 / 261120 [22-04-14 15:26:56.1308] Slim::Player::Player::_buffering (1155) +output... 3497600 / 1058400 [22-04-14 15:26:56.4270] Slim::Player::Pipeline::sysread (281) Pipeline doesn't have pending bytes - trying to get some from source [22-04-14 15:26:56.4284] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer [22-04-14 15:26:56.4294] Slim::Player::Pipeline::sysread (310) Wrote 16311 bytes to pipeline writer [22-04-14 15:26:56.4297] Slim::Player::Pipeline::sysread (281) Pipeline doesn't have pending bytes - trying to get some from source So question is why data stopped going into socketwrapper ? You need to get log from mixcloud bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Ok, found the problem...here's both a server.log including timestamps and the corresponding socketwrapperdebug.log +---+ |Filename: Desktop.zip | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=37700| +---+ pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
I noticed the missing timestamps, too, but I don't recall doing anything that would cause this..? Any idea where this can be changed ? pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
socketwrapper watchdog timer expires when no data has "moved" through the transcode chain within about 15 (maybe longer) seconds. The server.log seems to indicated that data has stopped arriving at transcode chain - more logging with timing is required to confirm this. However, there is something strange about your server.log - there are no timestamps on the entries - this is usually means the log conf file has been altered or corrupted. Please fix the log facility so that timings can be examined. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Hi, I attached server.log with player.source set to INFO. I've had the issue for quite some time now, it survived the Windows upgrade 10->11, a CPU change (Intel i7-3770T => i9-11900T) and the change from Avira to Avast. Problem occurs also when Avast is completely turned off. I _think_ the "2:30 WAV-thought" doesn't apply here, because different tracks stop much later. Unfortunately I can only test on Windows - in the github-thread I mentioned above, @kwarklabs said "the convert.conf line matched is correct, the transcoding you are seeing is expected behaviour and is unavoidable without switching operating system/hardware.". On their machine the transcoding goes mp4->aac which differs from the way it is done on Windows (mp4->faad->flac), as far as I understand Another weird thing just happens: a mix seems to play through on Squeezelite-X. It still doesn't on both hardware players, though (classic2 and boom). This must be related to changes in socketwrapper 1.12beta. +---+ |Filename: server.log | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=37698| +---+ pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Quick reaction - need time to look at log but also provide full system details - some socketwrapper issues happen with version of Windows, CPU type and also security s/w Anything that fails at 2:30 - usually means problem with WAV as that is the maximum frame count of a CD quality audio file. Also sanity check is needed - does the same issues happen on non Windows setup ? So full details of what is being tested LMS, Mixcloud stream so that it can be replicated. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Hi guys, I am having trouble streaming using the Mixcloud-plugin, and it seems to be a Socketwrapper-issue. I just upgraded my socketwrapper.exe to the 1.12beta3-bpa that I found in this thread, but the problem is still there - I attached the output-log. When streaming long tracks, the music stops after a few minutes. Looks like this only occurs on Windows, because the conversion path is a little different than on other OSs. (Plugin-thread that lead me here: https://github.com/danielvijge/lms_mixcloud/issues/23) This one is a good example track, because it is over two hours long and the stop occurs quite quickly (at least on my machine) somewhere between 2min30 and 3min00: mixcloud://johndigweed/transitions-with-john-digweed-and-denney/ I hope someone can figure out what the problem is..? Thanks for your help !! +---+ |Filename: socketwrapperdebug.log | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=37696| +---+ pupvogel's Profile: http://forums.slimdevices.com/member.php?userid=38152 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > Just to summarise. If the problem re-occurs and you manage to get a > log. If socketwrappper is the problem then the "watchdog" messages will > appear in the log - as shown below. > Noted. Thanks again. gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > Ok. Thanks for the explanation and, well... basically for everything. :) Just to summarise. If the problem re-occurs and you manage to get a log. If socketwrappper is the problem then the "watchdog" messages will appear in the log - as shown below. Code: SW: 2019-10-25 12:21:41.286 MoveDataThreadProc for step 1 about to call ReadFile. SW: 2019-10-25 12:21:41.286 MoveDataThreadProc for step 1 got 8192 bytes, about to write data. SW: 2019-10-25 12:21:55.305 Watchdog expired - Thread for step 1 stalled. SW: 2019-10-25 12:21:55.305 Tidying up SW: 2019-10-25 12:21:55.307 Watchdog expired SW: 2019-10-25 12:21:55.307 Waiting for process step 0 to terminate SW: 2019-10-25 12:21:57.308 Tidying up - process for step 0 hasn't died or wait failed. wr=258 :0 SW: 2019-10-25 12:21:59.323 Tidying up - Thread for step 1 hasn't died. SW: 2019-10-25 12:21:59.323 Thread for step 1 streamed603 blocks totalling 0046DE64 (4644452) bytes SW: 2019-10-25 12:21:59.323 Exitcode for Thread 1 Code=259 SW: 2019-10-25 12:21:59.338 Socketwrapper has terminated. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Ok. Thanks for the explanation and, well... basically for everything. :) gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > Doesn't that happen only when activating player.source at DEBUG level? > Is people running with debug logs activated all the time? It's just my POV. People fiddle with settings and then forget. Best keep things simple. Nothing is omitted. The same log data is available in the pop up window. My version just made it a bit easier when dealing with somebody who was not familiar with command prompt and starting LMS from a command prompt. When Ralphy has completed moving LMS to Strawberry Perl - then it is likely there will be added flexibility. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > It generates huge log files which may cause problems and so I think not > for general use. Doesn't that happen only when activating player.source at DEBUG level? Is people running with debug logs activated all the time? gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > Oh, ok. Got it. Maybe Ralph could add the debug functionality too? > Sooner or later it might turn up to be useful to have (size difference > of the file appears negligible). Don't know if there are drawbacks in > having it, though. It generates huge log files which may cause problems and so I think not for general use. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > No. It is the same as Ralpy's just with saving logging info so I'd > rather there are only Ralphy produced binaries for Windows as he is > rebuilding whole Windows setup. Otherwise I'll have to create a github > repository, add code and another fork on the github. Oh, ok. Got it. Maybe Ralph could add the debug functionality too? Sooner or later it might turn up to be useful to have (size difference of the file appears negligible). Don't know if there are drawbacks in having it, though. > It may be quicker to use Windows search facility to look for document > "socketwrapperdebug.log"Yes, exactly my thinking in asking you the name. :-) gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > Thanks bpa! I'll use this then. I will report back anything strange > (hopefully nothing). > > Edit: maybe you should link it on github as well? No. It is the same as Ralpy's just with saving logging info so I'd rather there are only Ralphy produced binaries for Windows as he is rebuilding whole Windows setup. Otherwise I'll have to create a github repository, add code and another fork on the github. > Edit2: could you please remind us what the log file is going to be > named? The file is called *socketwrapperdebug.log* It will be stored in the temp file directory for the user running LMS as detailed in the environment variable TMP (which is defined by Windows as a designated temporary file area). TMP is usually set to be something like C:\Users\\AppData\Local\Temp - where is the userid on Windows (e.g. Admin) It may be quicker to use Windows search facility to look for document "socketwrapperdebug.log" bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > Looking through the github socketwrapper, the 32bit/64bit built test > versions of 1.12beta uses sle118's pull request with a Ralphy patch. > > Attached is my version of the above with logging added. > > To be a bit more correct, the logging file now goes to directory > specified by TMP environment variable which is usually in the Users > AppData\Local\Temp > > The version is called 1.12beta3-bpa to distinguish from all other > versions. Thanks bpa! I'll use this then. I will report back anything strange (hopefully nothing). Edit: maybe you should link it on github as well? gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Looking through the github socketwrapper, the 32bit/64bit built test versions of 1.12beta uses sle118's pull request with a Ralphy patch. Attached is my version of the above with logging added. To be a bit more correct, the logging file now goes to directory specified by TMP environment variable which is usually in the Users AppData\Local\Temp The version is called 1.12beta3-bpa to distinguish from all other versions. +---+ |Filename: socketwrapper-1.12beta3-bpa.zip | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=37417| +---+ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > For the moment I will keep your version in use, so that in case the > problem resurfaces I'll just need to activate debug on player.source to > see what's going on. > > I wish to thank you for all the help, really. Yes - logging will only happen if player.source is set to DEBUG. To be on the safe side, I'll post an updated version with the latest sle188's code changes. IIRC it deals with cases with more than 2 applications in transcoding chain - typically users who have brutefir or bit rate limiting or similar which add an extra stage. For the record (and others reading this) - the original 2019 discussion & fix 1.12beta started here https://forums.slimdevices.com/showthread.php?110455-Announce-Spotty-2-8-x-Spotify-Connect-for-your-Squeezebox=953882=1#post953882 mainly follow sle118, bpa and mherger comments - there are intervening discussions. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > My socketwrapper 1.12beta2 which creates the log file > \Windows\Temp\socketwrapperdebug.log is the *same as 1.11beta* - it > does *not* have the latest change from sle118. > > edit2: > > I'm mixed up - my 1.12beta2 is based on the 2019 version of 1.12beta (it > has a fix for Spotty) - so it is not the same as v1.11beta and not the > same as the 2022 version of 1.12beta. > > The 2019 1.12beta has the fix for spotty but I think it had a potential > bug. For the moment I will keep your version in use, so that in case the problem resurfaces I'll just need to activate debug on player.source to see what's going on. I wish to thank you for all the help, really. gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > For completeness, I'll check out my version of 1.12beta and the latest > github build. My socketwrapper 1.12beta2 which creates the log file \Windows\Temp\socketwrapperdebug.log is the *same as 1.11beta* - it does *not* have the latest change from sle118. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > I honestly don't know what to say. What could explain this? I am sorry, > I feel bad for wasting your time, bpa. You saw the logs, I wasn't > imagining things :-( You do/did have a problem. This was not imagination. When audio source is a file or an encoding in an audio stream - the problem can be reproduced easily. When the source is a network stream from a major service, problems can happen and then later disappear. I used to have an ADSL connection which in the ISP is serviced by an DSLAM. My IP address was one of a pool of IP addresses allocated by the DSLAM dynamically. I used to get days of errors and then long periods of no problems. I assumed the errors were in my systems until I found that when I was allocated one specific IP address (i.e one board in the DSLAM) I would get errors - there was a problem board in the DSLAM and the ISP would do nothing about it. In your case, the fact the numbers/playing duration seems to change depending on the player's buffer size - make me feel it is a network issue rather than a socketwrapper one. There are so many system between sources and your player - it is hard to pin one down and even worse there may be no " technical problem" as such just a case of systems getting jammed due to timing - like teeth in two meshing gears. Services like Spotify use CDNs (Content Delivery Networks such as Akamai) which have a distribution system which adjust itself and have caches everywhere so its behaviour may have changed. IIRC Some Danish LMS Spotty users seems to have had a regional issue recently. Windows also has its special issues like the Windows thread I referenced. This is the sort of issue Phillipe spent a lot of time with the "reliable" http handling. I don't know whether LMS or Spotty has the network connection to retrieve data from Spotty (I need to look at the plugin) - if it is LMS then it is possible we can do something. In short, I think this problem is likely to happen again to somebody but it is hard to predict. Just like the "http reliable" long tracks seems to be a key factor. With network issues, I try to (i) Identify how to reproduce the problem identically (i.e if necessary all caches including OS one are cleared) - which can mean rebooting the system between tests (easy for PCP setup, harder for Windows) (ii) reproduce the problem on another user's system You did good on (i) but I couldn't help with (ii) as I don't use Spotify If/When the problem re-occurs - I think priority may be to try to get another user to reproduce the issue as you have shown it can appear on a range of players and within minutes. For completeness, I'll check out my version of 1.12beta and the latest github build. Spotty threads should be monitored for any playing issues with long tracks. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Okay, I've now finished listening to the whole track through DAC32, which uses a more complex conversion rules (you'll see it in the log). All flawless. 37410 Now I am playing back the same track using the beta by Ralph Irving nd... it plays back without stopping. This, again, on the DAC32 with the complex conversion rule you can see in the attachment above.To say I am baffled would be an understatement. I am sure about the socketwrapper.exe versions, as I had been careful about renaming them with descriptive extensions. I will leave this play for a while and come back to see if it's stopped but it's at 16m50s now and I doubt it will stop, it always happened far sooner... Back and it's still going at 38m18s... I'll now try to use the original socketwrapper.exe, just for a laugh. And it's now at 54m55s and happily chugging along. I honestly don't know what to say. What could explain this? I am sorry, I feel bad for wasting your time, bpa. You saw the logs, I wasn't imagining things :-( gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > I wanted to wait till the entire track had played back but now, at > 32m18s, I think it's time to accept that something changed. What? You > mention using an older beta, while the socketwrapper beta I downloaded > from Ralph Irving on github had been compiled three days ago with some > cleaning up. Maybe something went wrong during the process? > > I will actually try to put back that version and see if now everything > plays back just fine with that one too (in which case, we'll probably > remain with a mystery on our hands but... I would not complain). The > other thing I am going to try is using it for other clients (DAC32, > Squeezelite, Boom). > > I will report back once the testing is complete but, maybe, in the > meantime you could have a look and see if there's a difference between > your source and that used by Ralph Irving to compile his beta? > > PS > I had no window opening during playback but socketwrapperdebug.log is > being created in the location you mentioned. Just thought it was worth > pointing this out. > > PPS > On SB2 file played back in its entirety with no problem. This is the > log, just in case. Bugs with network streams can be very fickle especially if they are prone to timing issues. Three possibilities come to mind. 1. The logging of info has changed the dynamic of the processing. 2. the version of socketwrapper is not quite the same as the build you did earlier testing. 3. Network conditions have changed or something in CDN has changed. If you revert back to previous version and bug reappears then 3 is eliminated I'll check code to verify option 2 and maybe make a "lighter" version to see if 1 is an issue. I'll also look at log in case something is there. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > With file based problems -process is repeatable. > With stream based problems, it is rarely exactly repeated as packets can > take longer/slower to arrive and so have different number - so unless > problem is a data encoding issue - bytes received will vary. > > I have patched up a version of 1.12beta (from Nov 2019) so not quite the > same as github 1.12beta but it save socketwrapper log in a file in > \Windows\Temp > > Attached is the socketwrapper 1.12beta2 file zipped. Unzip, rename > existing socketwrapper so you can revert and save the attached version > in Bin/MSwin32 etc try this version. Ideally try SB2 as it is shortest > time until an issue. > No need to restart LMS, just logging enable player.source to DEBUG > > Play till it stops. A window with socketwrapper logging should open up > while playing and disappear when stopped. > > Check for file in\Windows\Temp\socketwrapperdebug.log - zip and attach > to a post. I wanted to wait till the entire track had played back but now, at 32m18s, I think it's time to accept that something changed. What? You mention using an older beta, while the socketwrapper beta I downloaded from Ralph Irving on github had been compiled three days ago with some cleaning up. Maybe something went wrong during the process? I will actually try to put back that version and see if now everything plays back just fine with that one too (in which case, we'll probably remain with a mystery on our hands but... I would not complain). The other thing I am going to try is using it for other clients (DAC32, Squeezelite, Boom). I will report back once the testing is complete but, maybe, in the meantime you could have a look and see if there's a difference between your source and that used by Ralph Irving to compile his beta? PS I had no window opening during playback but socketwrapperdebug.log is being created in the location you mentioned. Just thought it was worth pointing this out. gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > So... same order of magnitude, respectively, for the two cases... but > different numbers nonetheless. With file based problems -process is repeatable. With stream based problems, it is rarely exactly repeated as packets can take longer/slower to arrive and so have different number - so unless problem is a data encoding issue - bytes received will vary. I have patched up a version of 1.12beta (from Nov 2019) so not quite the same as github 1.12beta but it save socketwrapper log in a file in \Windows\Temp Attached is the socketwrapper 1.12beta2 file zipped. Unzip, rename existing socketwrapper so you can revert and save the attached version in Bin/MSwin32 etc try this version. Ideally try SB2 as it is shortest time until an issue. No need to restart LMS, just logging enable player.source to DEBUG Play till it stops. A window with socketwrapper logging should open up while playing and disappear when stopped. Check for file in\Windows\Temp\socketwrapperdebug.log - zip and attach to a post. +---+ |Filename: socketwrapper.zip| |Download: http://forums.slimdevices.com/attachment.php?attachmentid=37404| +---+ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > I'll have the detailed Windows instructions soon but if this issue was > the socketwrapper watchdog - I would have expected the played duration > to be the same as it is a timer based on stopped activity - however I'm > not sure as it is now 1.12beta. Don't know if this could be relevant. But the interruption does not appear to be constant, per player. I replayed the same track on Squeezelite-X and I got: Code: [22-03-07 17:59:31.6458] Slim::Player::Source::_readNextChunk (378) end of file or error on socket, song pos: 203881560 Before it happened at 176168024 Tried again on SB2 and I got: Code: 22-03-07 18:09:06.4100] Slim::Player::Source::_readNextChunk (378) end of file or error on socket, song pos: 26566784 Before it happened at 15073408. So... same order of magnitude, respectively, for the two cases... but different numbers nonetheless. gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Bad news re socketwrapper log. Something has changed since I last debugged socketwrapper ( a few years ago) not sure if it is a Win10 or an LMS change but the socketwrapper output is now a separate window and one which disappears when socketwrapper ends so no chance of finding out why it stopped. Just opened Visual studio on the system and the last project was socketwrapper 1.12beta - Nov 2019 !! when I was checking the suggested patch. I'll see if I can build a veriosn which saves socketwrapper log as a file. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > Yup, it stopped after 1m50s more or less. I'll have the detailed Windows instructions soon but if this issue was the socketwrapper watchdog - I would have expected the played duration to be the same as it is a timer based on stopped activity - however I'm not sure as it is now 1.12beta. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > What version of squeezelite (Squeezelite-X) are you running just in case > you are not having this issue > https://forums.slimdevices.com/showthread.php?113554-SqueezeLite-on-Windows-pausing-interruption-dropout-of-audio-every-5-minutes Player Model: Squeezelite-X Player Type: squeezelite Firmware: v1.9.9-1372 But there are absolutely no pauses, dropouts, etc. when playing local audio. Plus, as mentioned, Spotty exhibits the problem on SB2 and Booms as well. gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > > Can you try playing the stream on an SB2 to see if problem shows with > the smaller buffer players. Sure, I described the same behavior on different clients in the other discussion but I am starting that track now on SB2 to provide you an up to date report on how it behaves. [waits...] Yup, it stopped after 1m50s more or less. Code: [22-03-07 16:31:42.3602] Slim::Player::Source::_readNextChunk (355) Read to end of file or pipe [22-03-07 16:31:42.3603] Slim::Player::Source::_readNextChunk (378) end of file or error on socket, song pos: 15073408 [22-03-07 16:31:42.3604] Slim::Player::Source::_readNextChunk (383) 00:04:20:05:a3:8a mark end of stream [22-03-07 16:31:42.3607] Slim::Player::StreamingController::_eventAction (270) 00:04:20:05:a3:8a: LocalEndOfStream in PLAYING-STREAMING -> Slim::Player::StreamingController::_Streamout [22-03-07 16:31:42.3608] Slim::Player::StreamingController::_setStreamingState (2387) new streaming state STREAMOUT [22-03-07 16:31:42.3609] Slim::Player::StreamingController::_eventAction (302) 00:04:20:05:a3:8a: LocalEndOfStream - new state PLAYING-STREAMOUT [22-03-07 16:31:42.5413] Slim::Player::StreamingController::_eventAction (270) 00:04:20:05:a3:8a: StatusHeartbeat in PLAYING-STREAMOUT -> gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
What version of squeezelite (Squeezelite-X) are you running just in case you are not having this issue https://forums.slimdevices.com/showthread.php?113554-SqueezeLite-on-Windows-pausing-interruption-dropout-of-audio-every-5-minutes bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > 310,603,776 bytes (296MB approximately) is the size of the full FLAC > file, clocking in at 1 hour and 3 seconds. I am not familiar with your > calculations above, unless those lenghts are PCM lenghts for some > reason. But basically I don't understand what you're calculating. If you > need extra info in this regard, I'd be happy to provide anything I can. CD quality is 44100 samples/sec. Each channel has 1 sample - 2 channels means 2 samples Sample size is 16bits = 2 bytes - so data rate is 44100*2*2 = 176400 bytes/sec I'm mixed up this time. The data stream to player is flac - so estimate time would be 16mins. > In this case it's Squeezelite-X, so a squeezelite instance, set with "-b > 16384:16384". > > Edit: I have a SB2, several Booms and a DAC32 if you would like me to > test on other clients. This means player has 16Mbytes input and 16Mbytes of output. So input buffer has become full and some of output as well, and then no data would be required for a very long time. socketwrapper has a safety watchdog which kills a stream which hasn't "moved" (i.e. no data processed by transcode chain to player) for a long time. When player had small buffer sizes (e.g. SB2), there used to be problem with some internet stream blocking which would create zombie process under Windows. Can you try playing the stream on an SB2 to see if problem shows with the smaller buffer players. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > OK I now see from log that file is 44.1Khz, 16 bits sample 2 chan. (it > could have been other formats so don't assume anything)Sure, you're right. > > By my calc. Flac is usually 50% compressed. There are 176400 bytes/sec > for a standard CD stream > 176168024*2/176400 = 478sec = approx 8 mins. > 310,603,776 bytes (296MB approximately) is the size of the full FLAC file, clocking in at 1 hour and 3 seconds. I am not familiar with your calculations above, unless those lenghts are PCM lenghts for some reason. But basically I don't understand what you're calculating. If you need extra info in this regard, I'd be happy to provide anything I can. > > What is the player ? > If it is a squeezelite derived player how big are the buffers In this case it's Squeelite-X, so a squeezlite instance, set with "-b 16384:16384". Edit: I have a SB2, several Booms and a DAC32 if you would like me to test on other clients. gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > Nope. Full FLAC file (gotten through commandline listed above) is > 310601096 (it is an hour long track, after all). > > Edit: looking at the two "sizes", I would expect the track to stop after > about 30 minutes, but that's not the case. Strange... OK I now see from log that file is 44.1Khz, 16 bits sample 2 chan. (it could have been other formats so don't assume anything) By my calc. Flac is iusally 50% compressed. There are 176400 bytes/sec for a standard CD stream 176168024*2/176400 = 478sec = 8 mins. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > ok found it - I search I didn;t find it before > How many bytes in the 1hr 3secs flac file ? > is it 176168024 ? Nope. Full FLAC file (gotten through commandline listed above) is 310601096 (it is an hour long track, after all). gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > But first I need help with #2. OK, but it'll take a while as I have to find and boot up a Windows system. Windows is not my usual system. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > But to answer your question, yes, it's there at line 227 on the pastebin > I linked. ok found it - I search I didn;t find it before Code: [22-03-07 13:22:21.7121] Slim::Player::Source::_readNextChunk (355) Read to end of file or pipe [22-03-07 13:22:21.7124] Slim::Player::Source::_readNextChunk (378) end of file or error on socket, song pos: 176168024 How many bytes in the 1hr 3secs flac file ? is it 176168024 ? bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
bpa wrote: > OK good got a hard record of what should be output to the player. > > There could be many reasons for stopping after 5 mins - this thread is > only dealing with checking whether socketwrapper's watchdog or other > behaviour is killing the stream. > To know what is happening - you must get socketwrapper to generate log > output and then also see the end of the output. > > To get socketwrapper log which could detail why playing stops after 5 > mins > 1. Stop LMS running > 2. Open a command prompt windows, made it wide and long (use its own > menu) and then run LMS from the command prompt > 3. Enable player.source logging to DEBUG, this sets the "-D" option for > socketwrapper but as socketwrapper is run in its own process, this is > the only way to see its log output. > 4. Play the problem stream. > 5. The bad news is that LMS log will be mixed with socketwrapper log in > the command prompt window and the windows is finite in length - so after > stream ends you need to CTRL/C and stop LMS so that the command prompt > output can be saved - use command prompt menu to "select All and then > "Copy" and then paste the saved log into text file, to zip and attach to > a post. Unfortunately you lose me at #2. I don't have a clue about running LMS from the command prompt. As far as the rest is concerned, I'll play with command prompt window buffer because I'm afraid that given the amount of text that player.source in debug mode outputs... by default it would truncate stuff. But first I need help with #2. bpa wrote: > Editing logs is never a good idea as sometimes it is the messages that > are missing or the order or timing or messages that holds clues. > Better to zip log file and attach to a post. > > Was there an "end of file" message in the log before editing, such as > > Code: > > > [22-03-06 17:59:54.5136] Slim::Player::Source::_readNextChunk (378) end of file or error on socket, song pos: 42161853 > > > My editing was limited, literally, only to deleting repeating lines of the same message I've quoted. I kept beginnings and ends of those sections, in order not to break "continuity". But to answer your question, yes, it's there at line 227 on the pastebin I linked. gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > Real life results are the track starts playing and it stops after about > 5 minutes. Editing logs is never a good idea as sometimes it is the messages that are missing or the order or timing or messages that holds clues. Better to zip log file and attach to a post. Was there an "end of file" message in the log before editing, such as Code: [22-03-06 17:59:54.5136] Slim::Player::Source::_readNextChunk (378) end of file or error on socket, song pos: 42161853 bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
gorman wrote: > I use, to test, the Amarok album by Mike Oldfield. Single track, > 1h00m03s long. > > Here is the log: https://pastebin.com/YaU33ZQx (I deleted a whole bunch > of repeating Slim::Player::Source::_wakeupOnReadable (414) > bc:5f:f4:bf:3e:71 lines to not exceed pastebin's limits). > > Real life results are the track starts playing and it stops after about > 5 minutes. > > If I use this commandline, I get the whole FLAC, one hour and three > seconds long: OK good got a hard record of what should be output to the player. There could be many reasons for stopping after 5 mins - this thread is only dealing with checking whether socketwrapper's watchdog or other behaviour is killing the stream. To know what is happening - you must get socketwrapper to generate log output and then also see the end of the output. To get socketwrapper log which could detail why playing stops after 5 mins 1. Stop LMS running 2. Open a command prompt windows, made it wide and long (use its own menu) and then run LMS from the command prompt 3. Enable player.source logging to DEBUG, this sets the "-D" option for socketwrapper but as socketwrapper is run in its own process, this is the only way to see its log output. 4. Play the problem stream. 5. The bad news is that LMS log will be mixed with socketwrapper log in the command prompt window and the windows is finite in length - so after stream ends you need to CTRL/C and stop LMS so that the command prompt output can be saved - use command prompt menu to "select All and then "Copy" and then paste the saved log into text file, to zip and attach to a post. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
[SlimDevices: Plugins] Spotty and socketwrapper 1.12beta
Following my attempt to troubleshoot a situation where Spotty would end up playing the first 1/2/3 minutes of a song and then skip to the following track in a playlist (or stop if it was the last track in a playlist), I ended up testing a new version of socketwrapper that apparently is targeted at fixing this kind of problems. (some history here: Test version is found here: https://github.com/Logitech/slimserver-tools/pull/3?#issuecomment-1059465862 I use, to test, the Amarok album by Mike Oldfield. Single track, 1h00m03s long. Here is the log: https://pastebin.com/YaU33ZQx (I deleted a whole bunch of repeating Slim::Player::Source::_wakeupOnReadable (414) bc:5f:f4:bf:3e:71 lines to not exceed pastebin's limits). Real life results are the track starts playing and it stops after about 5 minutes. If I use this commandline, I get the whole FLAC, one hour and three seconds long: Code: "C:\ProgramData\Squeezebox\Cache\InstalledPlugins\Plugins\Spotty\Bin\MSWin32-x86-multi-thread\spotty.exe" --enable-volume-normalisation -n Squeezebox -c "C:\ProgramData\Squeezebox\Cache\spotty\ba008d57" --single-track "spotify://track:7zq1yjQyLZbJGdltQk1dka" --bitrate 320 --disable-discovery --disable-audio-cache | C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\flac.exe --channels=2 --sample-rate=44100 --bps=16 --endian=little --sign=signed --ignore-chunk-sizes - -o test.flac Available for further testing whatever might be needed. PS Windows 10 Pro x64 19042.1526 LMS Version: 8.3.0 - 1646406015 @ Fri Mar 4 16:17:17 WEST 2022 Operating system: Windows 10 - EN - cp1252 Platform Architecture: 8664 Perl Version: 5.14.1 - MSWin32-x86-multi-thread Audio::Scan: 1.05 IO::Socket::SSL: 2.068 Database Version: DBD::SQLite 1.58 (sqlite 3.22.0) gorman's Profile: http://forums.slimdevices.com/member.php?userid=56 View this thread: http://forums.slimdevices.com/showthread.php?t=116078 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
