Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RoderickGI]

I was hopeful that IPv6 would be the problem. Alas, no. The problem exists without IPv6.

My router, which I have been using since February and didn't have this issue until June/July, does have a setting to turn on IPv6 for the local network. I think I may have even turned that on after using the router for a time, but I'm not sure if or when I did that.

Anyway, the Workstation and HTPC had IPv6 turned on in the NIC properties. Android Pie 9 on my phone seems to always have IPv6 turned on for WiFi connections. Mobile data connections can be set to IPv4, but there doesn't seem to be any setting for IPv4 only on WiFi. The phone, Workstation and HTPC all had IPv4 and IPv6 addresses in the router and on the NIC properties. Wireshark traffic was in IPv4.

So I turned off IPv6 for the local network in the router then rebooted the router, phone, and Workstation. All devices still had IPv4 and IPv6 addresses assigned internally to them, but the router didn't show IPv6 addresses for them, so I assume that the IPv6 addresses on the devices were self assigned.

The problem remained the same. Gizmo would connect to the HTPC but not to the Workstation, until after I started Bingo SSDP.

So I turned off IPv6 on the Workstation NIC, rebooted it and checked it had no IPv6 address. Then retested, and the problem remained the same.

Given that I could turn IPv6 off on the router, and that Gizmo still works with the HTPC, I won't test with a different router just yet. I'm doing some timing tests to see how long it takes before Gizmo won't connect to the Workstation again, after a successful connection and then closing Gizmo.

[RoderickGI]

Well, it seems that whatever the cause is, it kicks in after 2 minutes 8 seconds. 128 seconds. 2^7 seconds.

That seems like a very deliberate number for a timeout. There is no timeout on the HTPC, only the Workstation.

Any ideas as to what could be timing out?

[bob]

Well, it seems that whatever the cause is, it kicks in after 2 minutes 8 seconds. 128 seconds. 2^7 seconds.

That seems like a very deliberate number for a timeout. There is no timeout on the HTPC, only the Workstation.

Any ideas as to what could be timing out?

That is interesting...
Can you try the 25.0.88 build?

[RoderickGI]

I installed and tried the MC25.0.88 build as soon as it was out. Same issue.

I did find that JRiver for Android, which I haven't been using in these tests so far, does work and fixes the problem for Gizmo, Panel and MO 4Media in the same way that Bingo SSDP and PingTools does.

As it appears that the [ACK] response from the phone is silently dropped and not reported in Wireshark, I thought the problem I have might be related to the MTU size. i.e. The TCP frame size being larger than the MTU, with DF (Don't Fragment) set, would result in silently dropped frames. I did find that Jumbo Frames were turned on in my HTPC NIC properties, but not in my Workstation NIC properties, so I tried with that turned on. While I saw a change in the MTU and frame size of packets from the Workstation, it didn't fix the issue. Besides, the MSS (Maximum Segment Size) of all frame sizes in the original Failed and Successful Wireshark logs were set to 1460, which is below the default MTU of 1500 and should work fine. The actual packet sizes were much smaller than that as well. So no joy there.

I still haven't tried with an old router, but that entails some work in reconfiguring WiFi connections. If I find the time I shall try though.

[rec head]

I have been listening to a lot of music streamed to my phone the past couple days. When I connect it usually stays connected for a pretty long time but I still have the problem of songs stopping while playing. Each time I have been able to hit STOP on MO4media and then PLAY and it picks up right away.

I'm still having the problem of not being able to connect at all to the W10 HTPC sometimes. I think the W7 machine that I started running has worked every time I have tried to connect to it.

I don't think I have mentioned this before but I feel like I may have some HDMI related nonsense happening. When I first started looking at my problem of not at being able to connect to the library I thought it may have something to do with the HTPC's HDMI connection to the AVR. But I turned off the power saving features and a few other changes and thought that maybe I was crazy. Why would turning the rest of my gear on change anything on the HTPC? Well today using my Harmony to turn on the equipment as I usually do all the I noticed for sure that the HTPC's HDD light activated as if coming out of sleep. AFAIK the Harmony Activity doesn't send any commands to the HTPC at startup. I also think that the AVR has the HDMI CEC turned off. I don't think Nvidia has any CEC controls to turn off. I haven't had a chance to check settings so I'll have to dig around a bit.

[RoderickGI]

I haven't had a chance to get back to testing stuff on this issue. It takes quite some time.

However, for your information Rec Head, my Workstation that has this issue doesn't use HDMI for audio or video. Audio is analogue out to powered speakers. Video is via a DVI cable to the monitor. I'm using an AMD video card, not nVidia. Of course it has an HDMI port on it, but it isn't connected.

So I don't think HDMI would be the issue.

Harmony remotes, at least mine, defaults to sending some sort of power on command to all devices used in an Activity, unless you change that. Check your Harmony setup.

I did bite the bullet and update to Windows 10 Build 1903 on the Workstation yesterday. Same problem. Same solution.


I'm still open to new ideas to try Bob, or anyone else!

[Awesome Donkey]

I've been making changes in my setup, but no matter what I do the issue persists. I got a new Raspberry Pi 4 model B 4GB, replaced all hardwired ethernet cables, changed to another router, tried different devices, etc. but it all seems in vain. Not only does it happen on my phone, it also happens on an older phone, Nvidia Shield TV, etc. all at random.

I have to admit, I'm pretty stumped.

[bob]

I've been making changes in my setup, but no matter what I do the issue persists. I got a new Raspberry Pi 4 model B 4GB, replaced all hardwired ethernet cables, changed to another router, tried different devices, etc. but it all seems in vain. Not only does it happen on my phone, it also happens on an older phone, Nvidia Shield TV, etc. all at random.

I have to admit, I'm pretty stumped.

Me too.
The one thing in common is the problem always involves an android device and the current Windows 10 release 1903, correct?

[Awesome Donkey]

Nope, Android devices and a Raspberry Pi 4 4GB as the MC server in my case. But it did happen on the Windows server too (I've since disabled media network on Windows just in case it was messing with the Pi somehow).

Mind-boggling indeed.

[RoderickGI]

I only just upgraded to Windows Build 1903 on my Workstation on August 11th, and on the HTPC on July 29th.
The HTPC doesn't have the problem. The Workstation does, and has since at least June some time.

As above, I see the problem running a Client on my HTPC and trying to connect to the Workstation server. So not only when using an Android Client either.

The "Failed Connection" appears to be a TCP problem. I don't see the "Music Stops" problem, but I expect it is also a TCP problem, where the connection "times out".

[Awesome Donkey]

I've been doing a ton of testing and troubleshooting for the last two days using MC 25.0.92 running on everything trying to figure out why playback using a Raspberry Pi server suddenly stops when streaming to an Android phone. There's a couple conclusions I can make now with fairly good certainty...

1) It's not the phone. Happens with multiple phones, Nvidia Shield TV, etc.
2) It's not the router (or firewall, port forwarding, etc.).
3) It's not the NAS.
4) Using a Windows server with both local content (via internally connected SATA hard drive) or via NAS works fine.
5) The issue seems to be limited to MC running on a Raspberry Pi. Both wired and wireless connections don't matter (and I switched out the ethernet cables, moved the Pi, used different ports, etc.) It's a brand new Raspberry Pi - my previous Pi also did the same thing.

So that makes me wonder, what in the world would be unique about the Pi server setup that this issue happens? I've triple checked all media network settings, and they match the media network settings on the working Windows server. Am I encountering some sort of rare Linux/ARM/Pi only MC bug? Is it a bug somewhere in the Pi's OS or even hardware (doubtful on hardware, since it's a new Pi and the old Pi also did it)? I don't think it's the remote apps either, because it happens in all of them (JRemote, MO 4Media, Panel and Gizmo).

I suppose my next step is to completely clear out the Pi's MC's settings and start from scratch without importing a library backup, to see if the issue still continues. If it does, I guess I might have to start looking into a mini PC or NUC running Windows to use as a server.

Very mind-boggling indeed.

[JimH]

Good information.  Thanks.

Are the files local?  If not, could you test with files located on the Pi's memory?

[bob]

I've been doing a ton of testing and troubleshooting for the last two days using MC 25.0.92 running on everything trying to figure out why playback using a Raspberry Pi server suddenly stops when streaming to an Android phone. There's a couple conclusions I can make now with fairly good certainty...

1) It's not the phone. Happens with multiple phones, Nvidia Shield TV, etc.
2) It's not the router (or firewall, port forwarding, etc.).
3) It's not the NAS.
4) Using a Windows server with both local content (via internally connected SATA hard drive) or via NAS works fine.
5) The issue seems to be limited to MC running on a Raspberry Pi. Both wired and wireless connections don't matter (and I switched out the ethernet cables, moved the Pi, used different ports, etc.) It's a brand new Raspberry Pi - my previous Pi also did the same thing.

So that makes me wonder, what in the world would be unique about the Pi server setup that this issue happens? I've triple checked all media network settings, and they match the media network settings on the working Windows server. Am I encountering some sort of rare Linux/ARM/Pi only MC bug? Is it a bug somewhere in the Pi's OS or even hardware (doubtful on hardware, since it's a new Pi and the old Pi also did it)? I don't think it's the remote apps either, because it happens in all of them (JRemote, MO 4Media, Panel and Gizmo).

I suppose my next step is to completely clear out the Pi's MC's settings and start from scratch without importing a library backup, to see if the issue still continues. If it does, I guess I might have to start looking into a mini PC or NUC running Windows to use as a server.

Very mind-boggling indeed.

We can do some more testing here with one of the test NUC's and Pi's.
I should be able to do this with any android device? Say a fireos tablet running GIzmo and simply playing a playlist of flac tracks not being converted and eventually it will stop?

[Awesome Donkey]

Hopefully. I'm also using read only authentication (name and pass both readonly). I'll test that next and see if using full authentication instead of read only makes a difference. Testing local files on the Pi will be next after doing full auth testing (though I'm sure I did test this at one point).

BTW, fully clean MC settings with only media network enabled (and the single album imported) still does it... at least with read only authentication enabled. I'll test it with full auth now.

EDIT: Full authentication also does it. Re-testing local files now.

EDIT 2: And that didn't take long, playing local files on the Pi's SD card (desktop) itself did it too. Double sure it's not the NAS now.

For convenience (and time saving) sake, I'm using MO 4Media right now for all these tests. I'll retest with JRemote and Panel later to re-confirm the results when I get more time. But yeah, the Windows test server works like a champ and the Pi doesn't. Super mind-boggling!

EDIT 3: Another thought occurs to me, I can also test this from another Linux (Arch Linux) server to see if it's related to MC for Linux as a whole or limited to MC for Linux running on ARM/Pi. I should also test MC for Mac too for good measure.

[Awesome Donkey]

Now this is kinda unexpected... MC for Linux running the server on Arch Linux seems to be working fine. And that would suggest that the issue is probably specific to the Raspberry Pi (or perhaps MC on Linux ARM, but I don't have a non-Pi ARM device to test that with).

For reference (and anyone wanting to reproduce my setup or settings), I'm using a Raspberry Pi 4 Model B 4GB running Raspbian Buster with all updates installed. This also happened with a Raspberry Pi 3 Model B+ running Raspbian Stretch. I also tested this with both local files (on the desktop of the Pi) and via a NAS, no difference. Also tried a clean MC install with nothing setup (and default media network settings except adding read-only authentication with readonly as the username and password but it happens with full auth too) and just a single album imported. I've tried this on Android phones (one running Android 7 Nougat and the other Android 9 Pie) so it may happen on tablets too, but I don't have an Android tablet to test on. Also I've been using MO 4Media as the remote on these phones, but that likely doesn't matter as it happened before with JRemote, Panel, Gizmo, etc. Will retest that here in a bit.

EDIT: As expected, it happened with JRemote too.

EDIT 2: And as expected it happened with Panel too.

[bob]

Now this is kinda unexpected... MC for Linux running the server on Arch Linux seems to be working fine. And that would suggest that the issue is probably specific to the Raspberry Pi (or perhaps MC on Linux ARM, but I don't have a non-Pi ARM device to test that with).

For reference (and anyone wanting to reproduce my setup or settings), I'm using a Raspberry Pi 4 Model B 4GB running Raspbian Buster with all updates installed. This also happened with a Raspberry Pi 3 Model B+ running Raspbian Stretch. I also tested this with both local files (on the desktop of the Pi) and via a NAS, no difference. Also tried a clean MC install with nothing setup (and default media network settings except adding read-only authentication with readonly as the username and password but it happens with full auth too) and just a single album imported. I've tried this on Android phones (one running Android 7 Nougat and the other Android 9 Pie) so it may happen on tablets too, but I don't have an Android tablet to test on. Also I've been using MO 4Media as the remote on these phones, but that likely doesn't matter as it happened before with JRemote, Panel, Gizmo, etc. Will retest that here in a bit.

EDIT: As expected, it happened with JRemote too.

EDIT 2: And as expected it happened with Panel too.

And MC doesn't crash when this happens??

[Awesome Donkey]

Nope, MC is running just fine.

I've remoted into the Pi as it was playing, and watched it. MC doesn't do anything when it happens. I don't think it's a network issue with the Pi, because a) I watch the network on the Pi when it occurs, and it's still sending/receiving data and b) the remote session doesn't disconnect/reconnect, which would happen if there was a network issue and c) it happens with both wired and wireless and it... just stops playing (like the song is paused, but it's not). I can actually stop playback in the remote app and press play and it'll begin playing again from the start even though it'll randomly stop again.

[JimH]

Maybe it's lost its connection with the sound device.

[bob]

Nope, MC is running just fine.

I've remoted into the Pi as it was playing, and watched it. MC doesn't do anything when it happens. I don't think it's a network issue with the Pi, because a) I watch the network on the Pi when it occurs, and it's still sending/receiving data and b) the remote session doesn't disconnect/reconnect, which would happen if there was a network issue and c) it happens with both wired and wireless and it... just stops playing (like the song is paused, but it's not). I can actually stop playback in the remote app and press play and it'll begin playing again from the start even though it'll randomly stop again.

Testing on a IdPi with JRemote (iOS). Plays on and on. No hiccups. Not sure what's going on here...

[RoderickGI]

I wouldn't dismiss a network issue AD, as that is certainly what I am seeing with the failed connection issue.

It isn't a failure of the network, it is a timeout of the specific TCP conversation between the server and the client.

Do you see any consistency between the last time you press a button that would result in the client talking to the server (i.e. Play), and when playback stops? Perhaps 128 seconds, like my issue?

Or if you can run Wireshark or similar between the connection, perhaps using a switch with mirroring capability, watch for TCP session resets.

Another way that would give an indication would be to watch the MC Server in Services & Plug-ins, and see if traffic to the remote software stops at some time before the music stops. i.e. The Server sends a whole track across, or a big chunk of the track, and then just stops sending any more. In my testing network traffic continues on the connection, as shown in Wireshark, but MC stops reporting any traffic in Services & Plug-ins > Media Network, for the remote device IP Address.

[Awesome Donkey]

If it's a network issue, it must be limited to Raspberry Pis themselves. Using MC on Windows or Arch Linux as a server seem to work just fine. It's just something about the Raspberry Pi itself that has some sort of weird issue. Maybe it's a Raspbian OS issue? Some recent kernel update messing up wired/wireless drivers? It *could* explain why it worked for a long time with Raspbian Stretch until the first week or so of July and also why trying to use MC24 (which most certainly worked) also had the issue. The possibilities are just endless.

I suppose one thing I could do to test it is take the Raspberry Pi 3 Model B+ I still have, find an old image of Raspbian Stretch from around April and test it with that. I think I'll do just that.

I'll probably have to either go the Windows mini PC route or just buy a large SD card and load music onto that to listen to on the phone. We'll see, I'm not in any hurry at the moment.

[Awesome Donkey]

You guys are not going to believe it, but using a Raspbian Stretch image from April as a clean install on the Raspberry Pi 3 Model B+ (without doing any system updates) is working with MC 25.0.92. I'm already halfway through the test album.

So this has to be an issue in Raspbian itself and I'm thinking the issue is likely caused by the kernel (or its drivers), perhaps? Nonetheless, I think I'll set it up as the media server and not perform any system updates (and manually install MC updates) and do some more testing. This is the first time a Raspberry Pi has made it this far in nearly a month!

EDIT: Double confirm. Using older Raspbian Stretch from April without updating on the Raspberry Pi 3 Model B+ with MC works fine with the phones even after importing a library backup from the newer Pi, so it's not my settings causing it but something in Raspbian itself (kernel?). w00t, I got a working library server on a Pi again!

Anyone wanting to investigate this, you'll need a Raspberry Pi running the latest Raspbian Buster (or Stretch if you're using an older Raspberry Pi) with all updates applied.

EDIT 2: It's made it through the album three times already! So now I can triple confirm using older Raspbian works.

[bob]

You guys are not going to believe it, but using a Raspbian Stretch image from April as a clean install on the Raspberry Pi 3 Model B+ (without doing any system updates) is working with MC 25.0.92. I'm already halfway through the test album.

So this has to be an issue in Raspbian itself and I'm thinking the issue is likely caused by the kernel (or its drivers), perhaps? Nonetheless, I think I'll set it up as the media server and not perform any system updates (and manually install MC updates) and do some more testing. This is the first time a Raspberry Pi has made it this far in nearly a month!

EDIT: Double confirm. Using older Raspbian Stretch from April without updating on the Raspberry Pi 3 Model B+ with MC works fine with the phones even after importing a library backup from the newer Pi, so it's not my settings causing it but something in Raspbian itself (kernel?). w00t, I got a working library server on a Pi again!

Anyone wanting to investigate this, you'll need a Raspberry Pi running the latest Raspbian Buster (or Stretch if you're using an older Raspberry Pi) with all updates applied.

EDIT 2: It's made it through the album three times already! So now I can triple confirm using older Raspbian works.

Sigh.
That doesn't bode very well for the new IdPi4 I'm working on. 

[Awesome Donkey]

Yikes, hopefully it's not affected, but you never know.

[bob]

Yikes, hopefully it's not affected, but you never know.

It will be if it's truly a buster kernel or stock package bug.

[Awesome Donkey]

I'll keep checking and testing every major kernel release for Raspbian. I was trying to look through Raspbian/kernel bug reports, but not knowing exactly where the issue is (Ethernet/WiFi drivers in the kernel?) kinda makes it hard. I mean, what regarding the kernel, drivers or stock packages could potentially cause this issue? I wonder if anyone else has been successfully in reproducing this issue yet?

And it's not just Buster, if you update Stretch it'll do the same thing (which is what I was using when I first noticed this).

EDIT: Looks like Raspbian was updated on July 10th, which is right around when I first started noticing this issue: https://downloads.raspberrypi.org/raspbian/release_notes.txt

2019-07-10:
  * Clearer options for switching of Pi 4 video output in Raspberry Pi Configuration
  * Option added to Appearance Settings to move taskbar to second monitor
  * Option added to Recommended Software to restrict package installs by architecture
  * New version of Adobe Flash player (32.0.0.223)
  * Selection of screen refresh rates added to Screen Configuration
  * Fix for missing text insertion cursor in LibreOffice on Pi 4
  * Fix for Wi-fi interruption when Wi-fi icon on taskbar is clicked
  * FIx for incorrect desktop background behind desktop login prompt
  * Fix for segmentation faults when launching obconf and lxapperarance
  * Fix for unclosed file pointer in Screen Configuration
  * Fix for Bluetooth plugin freeze when large numbers of devices detected
  * Fix for opening URLs not working in lxterminal
  * Fix for start menu opening on incorrect monitor when launched from keyboard
  * Fix for taskbar item not having [] removed when un-minimising on second monitor
  * Linux kernel 4.19.57
  * Raspberry Pi firmware 356f5c2880a3c7e8774025aa6fc934a617553e7b

[JimH]

Flash?

[bob]

I'll keep checking and testing every major kernel release for Raspbian. I was trying to look through Raspbian/kernel bug reports, but not knowing exactly where the issue is (Ethernet/WiFi drivers in the kernel?) kinda makes it hard. I mean, what regarding the kernel, drivers or stock packages could potentially cause this issue? I wonder if anyone else has been successfully in reproducing this issue yet?

And it's not just Buster, if you update Stretch it'll do the same thing (which is what I was using when I first noticed this).

EDIT: Looks like Raspbian was updated on July 10th, which is right around when I first started noticing this issue: https://downloads.raspberrypi.org/raspbian/release_notes.txt

Noting too obvious there, except the kernel. Does it happen for you on both wifi and ethernet?

[Awesome Donkey]

Yep, it happens on both Wi-Fi and ethernet with the Raspberry Pi 4 with all the latest updates. The Pi 3 Model B+ on the other hand that hasn't had any system updates has worked perfectly all weekend.

[rec head]

I know we've drifted to the Pi but my W10 server is definitely going to sleep. I have no idea why. Power settings are all set to NEVER for sleep, hibernate, turn off the screen, etc. It probably explains why I can't connect from any type of device sometimes. Doesn't help with the random stops.

[Awesome Donkey]

Regarding my issue, looks like new updates including a kernel update and bootloader update is out for Raspbian Buster. I'll update my Pi 4 and test MC streaming to remote with it to see if by chance the underlying issue might be fixed.

EDIT: And believe it or not, it's working so far and it made it past the first song and nearly through the second. Lots more tests to do though. I'm pretty hopeful about it now though.

EDIT 2: And it made through the test album twice now. Looks like the underlying issue, whatever it was, was fixed in the latest updates to Raspbian Buster. Bob, assuming this is indeed the case (which it's looking like it is) if you update the IdPi4 you're working on to the latest kernel/bootloader/etc. updates, it hopefully shouldn't encounter that issue when streaming to remotes.

[bob]

Regarding my issue, looks like new updates including a kernel update and bootloader update is out for Raspbian Buster. I'll update my Pi 4 and test MC streaming to remote with it to see if by chance the underlying issue might be fixed.

EDIT: And believe it or not, it's working so far and it made it past the first song and nearly through the second. Lots more tests to do though. I'm pretty hopeful about it now though.

EDIT 2: And it made through the test album twice now. Looks like the underlying issue, whatever it was, was fixed in the latest updates to Raspbian Buster. Bob, assuming this is indeed the case (which it's looking like it is) if you update the IdPi4 you're working on to the latest kernel/bootloader/etc. updates, it hopefully shouldn't encounter that issue when streaming to remotes.

Thanks!!

[Awesome Donkey]

I've streamed the test album 4 times, along with about 10 other songs without any issues.

So yeah, looks like it's fixed. YAY!

[RoderickGI]

I guess that fixes your "Stop in the middle of a track/playlist" problem AD. But Rec Head has reported that problem on a Windows server. (I haven't noticed it, but haven't tested a lot.)

There is still the issue of not being able to connect to a Windows based MC Server from Gizmo, MO 4Media, Panel, or Tremote, and when that happens, using one of multiple applications (PingTools, BingoSSDP, JRiver for Android) appears to clear the problem.

Maybe if the kernel change that caused the stop on the Pi was known, some light may be shed on the Windows issue.


Rec Head, even if your Windows 10 Server is going to sleep, Gizmo should wake it as soon as you try to connect. Gizmo send WOL Magic Packets when it tries to connect.

Also, a Windows MC Server should definitely not go to sleep while audio is playing, and that can easily be checked by looking at the MC "Help > System Info > Power" display, which will show "Playback (disable automatic sleep)" when audio is playing.

Can you check your Wake On LAN (WOL) capabilities and settings on your server?

I haven't read back to check, but if your W10 Server is connected to your LAN via ethernet, it should work, if the settings are correct. If the Server connects via Wi-Fi, then the Wi-Fi adapter needs to be capable of WOL, and not all are. But again, settings.

On ethernet, open your Network Adapter Properties, and then Configuration > Advanced tab. You should find things like "Wake on Magic Packet" which should be Enabled, and "WOL Shutdown & Link Speed" which I have set at "10 Mbps First". There will also be a "Wake on pattern match" but you shouldn't need that. There are also settings under Configuration > Power Management tab that need to be on.

Also, did WOL ever work for that Server?


Finally, if your issue is just that your Server is going to sleep and won't wake, then it is different to mine. Gizmo wakes my Workstation no problem, but won't connect.

PS: Just to muddy the waters further, I just checked again that Gizmo wouldn't connect without my workarounds. Still true. Then I tested if Gizmo was still waking my Workstation MC Server from sleep when I tried to connect, which it did, and then Gizmo connected without using my workarounds!  I repeated that test to be sure:
Test Gizmo won't connect to the MC Server on my Workstation. Correct.
Manually Sleep Workstation that is running a MC Server.
Wait a minute.
Open Gizmo on my Android phone. The Workstation wakes and Gizmo connects.

So with a freshly woken MC Server, Gizmo connects. Agh!

[rec head]

I'm hesitant to say I solved the problem but I finally had the chance to check the settings on my Harmony remote. Over the past year I had problems using the Harmony to connect to the HTPC via bluetooth. The Harmony would just forget the HTPC. A couple months ago I returned to controlling the HTPC via IR. It has been a long time since I first bought and setup the IR receiver but it has always been connected. Yesterday I checked and the Harmony was issuing a command to turn off the HTPC when I hit the power button. I changed the setting to always leave the HTPC on. I have been able to connect to the HTPC since. I have only done intermittent listening so I can't speak to the "stop while playing" issue.

[rec head]

The good news is that I think the Harmony command to turn off the HTPC was in fact why I wasn't able to always connect. I don't think I have had connecting ever since.

I still have the problem of random stops. I think it is always in the middle of a song. So far just hitting play will start the song over and I'm good for a while. Whenever I do extended listening from a client I am doing something else so it is hard to remember specifics.

[RoderickGI]

Every now and then I have another go at this issue again, to see if an update to Windows or MC has made a difference. No luck so far. But then I read back through all the testing I did for this issue, and found these two little pearls:

I think I found the "stop in the middle of a song" issue.
It's likely from adding the Send timeout in 25.0.81 (change #9). On devices with large buffers, the TCP window will close for longer than the send timeout causing the socket to close.

Rec head, try running a continuous ping -t from the windows maching to something on your LAN, like the router or NAS, to see if that prevents your network card from going to sleep.  Leave it running overnight and see if your results improve.

Now that wasn't a direct answer, but it suggested something I had not tried before. Combining that with the knowledge that Gizmo won't connect to my Workstation MC Server until I run something on the phone that uses SSDP (SSDP Bingo, PingTools, JRiver for Android), which I always assumed opened a connection from the phone to the Workstation, which Gizmo was then able to use to connect to the MC Server. i.e. The SSDP packets opened a TCP Window to the Workstation, and that stayed open long enough for Gizmo to connect.

So I tried this.
1. Tried to connect Gizmo to the MC Server on my Workstation. It failed as usual.
2. Ran Ping in a Command Window on the Workstation, and pinged the phone.
3. Tried to connect Gizmo to the MC Server on my Workstation. It worked.

On the first test run I used a continuous ping, Workstation to Phone. On the second test run I just did a standard ping, four packets.  It worked every time. Even running ping while Gizmo was trying to connect, and failing, enabled it to connect, immediately.

This issue with Gizmo stopping playback of video via Chromecast got me thinking along these lines.
https://yabb.jriver.com/interact/index.php/topic,125204.msg867183.html#msg867183


Bob, does the above shed any more light on why Gizmo doesn't connect without some other connection first?

[bob]

Every now and then I have another go at this issue again, to see if an update to Windows or MC has made a difference. No luck so far. But then I read back through all the testing I did for this issue, and found these two little pearls:

Now that wasn't a direct answer, but it suggested something I had not tried before. Combining that with the knowledge that Gizmo won't connect to my Workstation MC Server until I run something on the phone that uses SSDP (SSDP Bingo, PingTools, JRiver for Android), which I always assumed opened a connection from the phone to the Workstation, which Gizmo was then able to use to connect to the MC Server. i.e. The SSDP packets opened a TCP Window to the Workstation, and that stayed open long enough for Gizmo to connect.

So I tried this.
1. Tried to connect Gizmo to the MC Server on my Workstation. It failed as usual.
2. Ran Ping in a Command Window on the Workstation, and pinged the phone.
3. Tried to connect Gizmo to the MC Server on my Workstation. It worked.

On the first test run I used a continuous ping, Workstation to Phone. On the second test run I just did a standard ping, four packets.  It worked every time. Even running ping while Gizmo was trying to connect, and failing, enabled it to connect, immediately.

This issue with Gizmo stopping playback of video via Chromecast got me thinking along these lines.
https://yabb.jriver.com/interact/index.php/topic,125204.msg867183.html#msg867183


Bob, does the above shed any more light on why Gizmo doesn't connect without some other connection first?

Anything I say here will be a total guess of one sort or another.
The ping to the phone succeeding will create an arp entry on both the windows PC and the phone.
The phone and/or windows machines might be doing convoluted IPv6 stuff. Many phones do that by default now.
Is your windows machine IPv6 stack turned on? You don't have control of this on the phone but you do on windows.

[RoderickGI]

This one is the issue I think.

The ping to the phone succeeding will create an arp entry on both the windows PC and the phone.

Well, a possibility. I didn't know that the PC and Phone created ARP entries, in addition to what is in the router. I use IP Address reservation in the router for all my devices, so I thought the ARP entries there would be constant.

I have turned off IPv6 in the router and PC during testing in the past. That didn't make any difference. As you say though, I don't have any control over what the phone does. I don't even have visibility into what the phone is doing, with respect to internal networking. I've had a bit of a look for tools I could run on the phone to learn more, but haven't found anything yet.

I'll do some more research on phone networking, wrt ARP particularly. It just seems strange that the network packets I have seen in Wireshark don't also create the ARP entry, if that is the issue. Or "open a TCP Window", if that is the issue.

It could still be some obscure security in the phone, or a bug in the OS like Awesome Donkey saw on the Raspberry Pi 4.

Thanks for answering Bob.