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
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
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
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
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
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
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
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
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
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
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:
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
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
>
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.
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
Here is another log-combo, this time with Mixcloud-logging set to
debug.
Doesn't add too much info, though...
+---+
|Filename: Logs.zip |
|Download:
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:
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
Ok, found the problem...here's both a server.log including timestamps
and the corresponding socketwrapperdebug.log
+---+
|Filename: Desktop.zip |
|Download:
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
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
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
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.
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
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 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:
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
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
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 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
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.
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
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
>
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
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
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
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.
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
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
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
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
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
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
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
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
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:
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.
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
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.
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
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
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 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:
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
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
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
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).
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
58 matches
Mail list logo
