Print

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

[rec head]

Today was the first day that I have tried to solve what has been going on for at least a week or two. I am not always able to access audio from my phone. I used to be able to all the time. The problem does not happen all the time and after going over things today I thought I had it handled. The phone not connecting happens on Wifi on the same network and on 4G.

AFAIK I had made no network changes prior to the problem.

I have tried connecting with MO4media, Panel and Gizmo.

I reviewed the Media Network FAQs.

Today I went over all network and firewall settings I could think of on the HTPC the router and modem. I re-added some port forwarding rules. All IP addresses look correct when I'm trying to connect.

I have been using MC24 so I installed 25 latest release and nothing changed.

I have restarted the HTPC and the phone but because people were using the network for actual work I could not restart those.

It feels like something is going to sleep but my server is always on. I have not made any changes to Power settings. Has Windows changed anything lately that could be affecting this?

I'm not a network expert but I got this working before and can't see why it is busted now. Any help would be greatly appreciated.

[RoderickGI]

First, if it is happening on WiFi, don't worry about 4G and Port Forwarding yet. Wait until WiFi is reliable.

I don't think there have been any Windows changes that would cause intermittent loss of network connection, but sometimes network card driver changes can cause issues like that. Sometimes just a reboot of the PC fixes that, or manual update to a better driver. Sometimes a driver change can result in Windows being allowed to power down the network card, even though the PC itself doesn't go to sleep. Look under "Device Manager > right-click the network card you are using > Properties > Power Management" for a setting such as "Allow the computer to turn off this device to save power". Turn that off.

Next, are you using IP Address Reservations in the router? Because you should be. That should be under the LAN or DHCP section of your router configuration pages, but might be called something else. On my new router they are called "Static Leases". IP Address Reservations/Static Leases are not Static IP Addresses, even though they have the same effect. But they use DHCP so the router knows about the address without using discovery. It also ensures all IP Addresses are on the same subnet.

Could someone have assigned a Static IP Address to any device on the network? That can cause conflicts and results in loss of network connection.

Can you ping from your phone to the MC Server address? I haven't looked but there must be utilities for phones that enable that.

Router logs say anything?

You may need to wait until you can reboot the router. But I think an issue there is less likely than elsewhere, or settings in the router as above.

[rec head]

Thanks for all the help.

The "Allow the computer to turn off this device to save power" was checked. I don't know why. If I ever intentionally made that change it was a long time ago and media sharing had been working for a long time.

I haven't had enough time to see if that was the problem but it would explain why sometimes I could stream on the LAN or WAN and sometimes neither.

One more question would logging into the server from another wired PC client vs the phone behave differently? I can always log in from this PC and probably should have mentioned that.

The HTPC server does have an IP reservation. All my computers and AVR equipment that are on the LAN do.

Thanks again,  I really hope this is resolved.

[RoderickGI]

A lot of hardware will work fine with that setting checked. It just changes the way the network card is woken up when the PC is woken from sleep. So it shouldn't make any difference as your server is always on. If the hardware and drivers work properly, it doesn't matter. My HTPC with Broadcom based NIC has it checked and works fine, as does my Workstation PC with Intel based NIC. But I used to have different hardware and it made a difference.

So it could be something else, particularly as it worked before. Hence my other suggestions in the last post.

Rebooting the router may be all that was required. Have you done that yet?

[rec head]

I haven't touched the server since last night so any sleep or power saving should be enabled by now. I just tried connecting and it worked perfectly.

The power saving setting seemed to do the trick. Thanks again for pointing that out to me.

[rec head]

I spoke too soon. It is 3 hours later and I can't connect to the MC server. I used the HTPC (server) to listen to music then watched videos on Chrome (not through MC) and now I can't connect.

I restarted the router. No change. I can't even connect to the library from this PC which I don't remember ever happening.

EDIT: I closed Chrome on the HTPC and my phone connected immediately without me doing anything else.

[~OHM~]

if you're using W7, many months ago there was a update that broke some network settings. I was having issues seeing shared folders on my other computers. This went on for days till I finally googled the correct question and found the issue and the patch to fix it....just a thought

[rec head]

I still can't figure it out. To check the network I made a new library on this W7 PC and started the MC media server. I have been able to connect every time I tried. Right now I can't connect to the main HTPC server at all. I can connect to this PC's library instantly. Both libraries are using tracks from the same NAS and on the same wired network.

I just went upstairs and moved the mouse on the HTPC. Now I can connect to that server. It seems like something is causing the HTPC to sleep. AFAIK I have all sleep behavior OFF. I do have a screen saver start but no re-logon when coming out of the screen saver. I would like to keep the screen saver enabled because I have an OLED.

I previously turned off the network card power saver thanks to RoderickGI. Are there other W10 sleep or power settings besides the main ones that I can be missing?

Thanks

[RoderickGI]

Okay, I think you are seeing the same thing that I am seeing with my Workstation. This also started to happen to me recently, but I don't know exactly when.

Try this for me.
1. Find PingTools on Google Play and install it on your phone.
2. Wait until you can't connect to your HTPC server with Gizmo.
3. Open PingTools and let it do its thing, checking the network. Don't do anything other than open it. No button presses or anything. Just wait about 15 seconds.
4. Try connecting to the HTPC with Gizmo again.

Report back. I think Gizmo will connect.

[rec head]

Thanks. I downloaded PingTools and will try it if I have another problem.

For the record when I can't connect from my phone I can't connect from a client PC either.

In power settings I did find that the HDD's were set to power down after 20m. I changed that to Never. The system is on an SSD and the media is on a separate NAS so it shouldn't really matter(?).

Still testing.

[rec head]

I had the "stopped in the middle of a song" problem that I have heard people mention lately and when it happened I realized it has happened several times before.

I ran PingTools then went back to MO4media and it picked up no problem.

Any theory as to what is going on?

[RoderickGI]

For the record when I can't connect from my phone I can't connect from a client PC either.

Same for me. Tremote (another MC installation), Panel, Gizmo, MO 4Media all exhibit the same problem, when it occurs.

The strange thing is that I have never seen the problem on my HTPC, and I don't seem to get the stops in the middle of a track either. But if the problem occurs and one of the methods can't connect to my Workstation MC Server, then none of them can connect.

Any theory as to what is going on?

I no longer think it is a power management issue. I think it was a coincidence that the problem went away when you changed the NIC power feature, because the issue just comes and goes for me. I think you should change all those settings back again.

What I have seen through Wireshark is that my phone will send a request to the MC Server, and the MC Server will respond. But shortly after the phone will resend the request, and the MC Server will also resend the response. The communication is broken somehow.

I spent a lot of time with Wireshark, netstat commands, on the MC "Services & Plug-ins > Media Network" page looking at my MC Server logs, uninstalled Norton Security (still uninstalled), tamed Windows Defender... and found nothing definitive. Yet still the problem occurs.

When the problem exists, a http "DeviceDescription" record doesn't show up in the MC "Services & Plug-ins > Media Network" page. Opening PingTools results in such a record showing up, and then the problem goes away. It could be that the MC Server doesn't see the "DeviceDescription" request, and so will not respond to later requests for connection. That is what the Wireshark logs seem to show.


So, I think this is a MC issue, where something has gone wrong in the network communications. But I am out of my depth and can't think of what else to look at. The problem could still be a security software problem, where, for example, the reply from the MC Server to the MC Client (Phone App or MC installation) is blocked. If it only happened on the phone I would have removed Norton from the phone to test that already. But as you note, it happens with Tremote (MC Client) connections as well.

I think you issue, particularly now that you have reported playback stops in the middle of tracks, is the same as Awesome Donkey's issue, which I started commenting on here: https://yabb.jriver.com/interact/index.php/topic,114964.msg839945.html#msg839945

Have you seen reports fro other people on this issue? Knowing more people are seeing it may get more attention, and may help identify the cause. I haven't started a thread yet because I don't have specific evidence of anything, really.


If anyone at JRiver wants to look at a failed connection Wireshark log, I can share it. I don't think I should share it here as it is full of MAC Addresses and such.

[JimH]

Please send to bob at jriver and copy matt. Thanks.

[RoderickGI]

Done.

[Awesome Donkey]

I had the "stopped in the middle of a song" problem that I have heard people mention lately and when it happened I realized it has happened several times before.

So, you guys thinking the issues we've all been experiencing as of late (e.g. me with playback just stopping randomly in the middle of songs or switching to the next track suddenly for no reason when streaming to any remotes) might be connected and caused by a MC25 issue (perhaps DLNA issue)? Interesting...

I'm going to install MC24 on my Raspberry Pi and conduct the same tests I've been using with MC25 and JRemote/Panel/MO 4Media/Gizmo and see if I can repeat the issues there.

EDIT: Nope, playback suddenly stops with MC24 too. I'm completely stumped.

[AndrewFG]

When the problem exists, a http "DeviceDescription" record doesn't show up in the MC "Services & Plug-ins > Media Network" page. Opening PingTools results in such a record showing up, and then the problem goes away. It could be that the MC Server doesn't see the "DeviceDescription" request, and so will not respond to later requests for connection.

A Device Description is UPNP thing. So you could send the Wireshark log to me too if you want.

[rec head]

I just tried connecting to the my main server. No dice. The HDD power setting didn't help. Tried running PingTools and it didn't help.
Here is my setup if this helps.

*Main MC computer HTPC- this is my server as well as where I listen to music and watch movies
--Old i5 running W10.
--System on SSD all media on mapped NAS drives.
--1060 6GB video card -> Denon AVR -> LG OLED
--Intel onboard NIC wired connection
--Windows Defender is running but has been "tamed." Well it was a while ago but I haven't checked the settings since the taming.

*Client computer - The PC I am typing on. Usually only connected to the HTPC to do library maintenance.
--NUC running W7, wired connection
-- System on SSD all media on mapped NAS drives.
-- Windows security features at defaults.

*Phone is a Pixel 3
remotes I have installed are MO4Media, Panel and Gizmo.

*Home wifi is an eero mesh.

All software is updated on the normal schedules except I am using an older driver on the HTPC for the video card.

The problem I am having is that I either can't connect to the HTPC at all or I get dropped by it while a song is playing. When I can't connect I try different remotes and connecting on the NUC and it doesn't work.

I recently setup the NUC with a MC server and small library (1 artist) and have never had a problem connecting to it. Now every time I get bumped off the HTPC I try connecting to the NUC just to see if it is a network issue and I can connect.

I don't know anything about networking but can follow directions so if there is something to try spell it out for me.


EDIT: I just moved the mouse on the HTPC and was able to connect. The TV and AVR were both off when I did this. The HTPC is most often used at night for movie watching. Some days it might not be used directly at all but is always on. Yesterday afternoon for example the HTPC was had not been used for viewing for at least 12 hours when I connected with my phone to listen to music. Then during a song it dropped the connection. Using PingTools on my phone brought the connection back. Today the HTPC hadn't been used in about 10 hours and I could not connect at all. I had been watching a show last night and the HTPC was left in Theater View. Simply moving the mouse and waking the computer allowed me to connect. As noted in previous posts I have been disabling power saving features. I still use the screen saver but that comes on after 5 minutes so shouldn't be a factor. Oh, and the "mouse" is a track pad so I don't think that it was being inadvertently shaken and waking the computer.

[Awesome Donkey]

All these reported media network issues as of late is very strange stuff indeed. In my case I ran BubbleUPNP with logging enabled, and didn't notice anything special when playback suddenly stopped:

Code: [Select]

[main (2)                                ] INFO     - 0:00:12.751    - BubbleUPnP (cp3705AS): NextAVTransportURI: http://192.168.1.132:52100/Music/F628114.flac
[MediaRenderer-Looper (1326)             ] INFO     - 0:00:13.727    - GAPLESS: next onPrepared
[MediaRenderer-Looper (1326)             ] INFO     - 0:00:13.728    - track duration reported by MediaPlayer: 444
[main (2)                                ] INFO     - 0:00:17.289    - onPause()@8737978:30
[main (2)                                ] INFO     - 0:00:17.290    - removed listener: 3 listeners
[main (2)                                ] INFO     - 0:00:17.307    - removed listener: 2 listeners
[main (2)                                ] INFO     - 0:00:17.308    - removed listener: 1 listeners
[main (2)                                ] INFO     - 0:00:17.310    - removeListener (context: com.bubblesoft.android.bubbleupnp.MainTabActivity@8737978)
[main (2)                                ] INFO     - 0:00:17.312    - removed listener: 0 listeners
[main (2)                                ] INFO     - 0:00:17.345    - onStop()@8737978:30
[main (2)                                ] INFO     - 0:00:18.370    - ACTION_SCREEN_OFF
[main (2)                                ] SEVERE   - 0:00:18.376    - watchdog: enabled
[cling-36 (1390)                         ] WARNING  - 0:00:22.789    - .j                          : Client connection was aborted: d.e.b.a.a.r0.f: Connect to 169.254.11.101:63445 timed out: http://169.254.11.101:63445/upnp/xml/devices/MediaRenderer1.xml
[cling-36 (1390)                         ] WARNING  - 0:00:22.790    - .f                          : Device descriptor retrieval failed, no response: http://169.254.11.101:63445/upnp/xml/devices/MediaRenderer1.xml
[main (2)                                ] INFO     - 0:00:31.798    - performDeviceSearch: search done
[main (2)                                ] SEVERE   - 0:00:31.799    - watchdog: device search--: 2
[main (2)                                ] INFO     - 0:03:46.855    - ACTION_SCREEN_ON
[main (2)                                ] SEVERE   - 0:03:46.856    - watchdog: disabled
[main (2)                                ] INFO     - 0:03:47.860    - onRouteRemoved 6a32de1ac50b3437fccbab086dd1dea6 => MediaRouter.RouteInfo{ uniqueId=com.google.android.gms/.cast.media.CastMediaRouteProviderService:6a32de1ac50b3437fccbab086dd1dea6, name=SHIELD, description=SHIELD Android TV, iconUri=null, enabled=true, connecting=false, connectionState=0, canDisconnect=false, playbackType=1, playbackStream=-1, deviceType=1, volumeHandling=0, volume=0, volumeMax=20, presentationDisplayId=-1, extras=Bundle[{com.google.android.gms.cast.EXTRA_CAST_DEVICE="SHIELD" (6a32de1ac50b3437fccbab086dd1dea6)}], settingsIntent=null, providerPackageName=com.google.android.gms }
[main (2)                                ] INFO     - 0:03:47.861    - not removing cast device due to recent screen on or off
[main (2)                                ] INFO     - 0:03:48.113    - onRestart()@8737978:30
[main (2)                                ] INFO     - 0:03:48.118    - onStart()@8737978:30
[main (2)                                ] INFO     - 0:03:48.121    - onResume()@8737978:30
[main (2)                                ] INFO     - 0:03:48.123    - registered media button event receiver
[main (2)                                ] INFO     - 0:03:48.124    - added listener: 1 listeners
[main (2)                                ] INFO     - 0:03:48.127    - added listener: 2 listeners
[main (2)                                ] INFO     - 0:03:48.129    - source changed: Playlist
[main (2)                                ] INFO     - 0:03:48.130    - selected item changed: Shine On You Crazy Diamond (Parts I-V)
[main (2)                                ] INFO     - 0:03:48.136    - setSeekBarDetailsText: FLAC • 44.1 kHz • 16 bits • Stereo • Vol 13
[main (2)                                ] INFO     - 0:03:48.139    - setSeekBarDetailsText: FLAC • 44.1 kHz • 16 bits • Stereo • Vol 13
[main (2)                                ] INFO     - 0:03:48.140    - setSeekBarDetailsText: FLAC • 44.1 kHz • 16 bits • Stereo • Vol 13
[main (2)                                ] INFO     - 0:03:48.146    - added listener: 3 listeners
[qtp179090117-1493 (1493)                ] SEVERE   - 0:03:48.152    - watchdog: Jetty request++: 3
[main (2)                                ] INFO     - 0:03:48.152    - added listener: 4 listeners
[qtp179090117-1493 (1493)                ] WARNING  - 0:03:48.153    - no current decode info found for item key: c228e5fc-a1f9-ff3f-0000-000010e3498d_F628113
[main (2)                                ] INFO     - 0:03:48.154    - addListener (context: com.bubblesoft.android.bubbleupnp.MainTabActivity@8737978)
[qtp179090117-1493 (1493)                ] SEVERE   - 0:03:48.157    - watchdog: Jetty request--: 2
[main (2)                                ] INFO     - 0:03:50.392    - onRouteAdded 6a32de1ac50b3437fccbab086dd1dea6 => MediaRouter.RouteInfo{ uniqueId=com.google.android.gms/.cast.media.CastMediaRouteProviderService:6a32de1ac50b3437fccbab086dd1dea6, name=SHIELD, description=SHIELD Android TV, iconUri=null, enabled=true, connecting=false, connectionState=0, canDisconnect=false, playbackType=1, playbackStream=-1, deviceType=1, volumeHandling=0, volume=0, volumeMax=20, presentationDisplayId=-1, extras=Bundle[{com.google.android.gms.cast.EXTRA_CAST_DEVICE="SHIELD" (6a32de1ac50b3437fccbab086dd1dea6)}], settingsIntent=null, providerPackageName=com.google.android.gms }
[main (2)                                ] INFO     - 0:03:50.392    - not adding already added cast device
[main (2)                                ] INFO     - 0:03:52.306    - onPause()@8737978:30
[main (2)                                ] INFO     - 0:03:52.307    - removed listener: 3 listeners
[main (2)                                ] INFO     - 0:03:52.309    - removed listener: 2 listeners
[main (2)                                ] INFO     - 0:03:52.310    - removed listener: 1 listeners
[main (2)                                ] INFO     - 0:03:52.311    - removeListener (context: com.bubblesoft.android.bubbleupnp.MainTabActivity@8737978)
[main (2)                                ] INFO     - 0:03:52.312    - removed listener: 0 listeners
[main (2)                                ] INFO     - 0:03:52.341    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.342    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.343    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.344    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.357    - onDestroy: start
[main (2)                                ] INFO     - 0:03:52.414    - .n                          : AndroidUpnpService.onDestroy() took: 57 ms
rec head would you happen to have multiple servers running MC by chance? I did notice an instance where I had MC running media network on multiple devices (PC, Pi, etc.) where if I disabled media network on the PC while music was playing on a phone from the Pi, it'd instantly stop. Might be a coincidence but you never know. Wish there was an easier way to log/document all this stuff.

[JimH]

Awesome Donkey,
I think you said you have problems with MC24 as well now, so it can't be a change in MC.

Antivirus / security software?

Windows updates?

I agree that something strange is going on.

[Awesome Donkey]

No changes at all. And no AV, of course (Defender is tamed like a little puppy).

I guess I could try downgrading MC builds released before the first week of July when I first noticed this happening, but since it happened with MC24 too it makes me wonder. I suppose it could be caused by an OS update, but not sure if it's the phone itself, Windows, the Pi, etc. So many variables!

I think I'm going to install Wireshark on the Pi and do some sniffing and see what happens.

EDIT: I have a Wireshark capture at the moment playback stops.

[JimH]

No changes at all. And no AV, of course (Defender is tamed like a little puppy).

Funny.  I have a little puppy and he is pooping all over.

[bob]

No changes at all. And no AV, of course (Defender is tamed like a little puppy).

I guess I could try downgrading MC builds released before the first week of July when I first noticed this happening, but since it happened with MC24 too it makes me wonder. I suppose it could be caused by an OS update, but not sure if it's the phone itself, Windows, the Pi, etc. So many variables!

I think I'm going to install Wireshark on the Pi and do some sniffing and see what happens.

EDIT: I have a Wireshark capture at the moment playback stops.

Would you email me a copy? (and log if you have one)?

I think there are two issues here that may or may not be connected.

Moving the mouse to get a connect really points to the OS as being the issue.

Playback stopping in the middle of a track may or may not be related. I'm making a test build to disable the detection of other controllers on a per DLNA zone basis. When a device stops because of that it's logged with explicit message stating that. You should check your logs.

[Awesome Donkey]

You've got mail, Bob. I really hope it tells you what's going on. I stopped the Wireshark capture and closed MC within 10 to 20 seconds of the song suddenly stopping in the middle. Both this capture and MC log were taken at the same time (though the capture started a minute or two after starting the song).

There's actually two issues I encounter; 1) playback suddenly stopping at random during a song and 2) during playback of a song, it'll suddenly stop and start playing the next song. The second one is particularly odd indeed. Nonetheless, for my testing I'm using Pink Floyd's Wish You Were Here (and it's during the first song it'll randomly stop and/or start playing the next song).

[rec head]

rec head would you happen to have multiple servers running MC by chance?

Yes I now have 2 servers but I only started the 2nd server after the main one (HTPC) started giving me problems.

I recently setup the NUC with a MC server and small library (1 artist) and have never had a problem connecting to it. Now every time I get bumped off the HTPC I try connecting to the NUC just to see if it is a network issue and I can connect.

[bob]

All these reported media network issues as of late is very strange stuff indeed. In my case I ran BubbleUPNP with logging enabled, and didn't notice anything special when playback suddenly stopped:

Code: [Select]

[main (2)                                ] INFO     - 0:00:12.751    - BubbleUPnP (cp3705AS): NextAVTransportURI: http://192.168.1.132:52100/Music/F628114.flac
[MediaRenderer-Looper (1326)             ] INFO     - 0:00:13.727    - GAPLESS: next onPrepared
[MediaRenderer-Looper (1326)             ] INFO     - 0:00:13.728    - track duration reported by MediaPlayer: 444
[main (2)                                ] INFO     - 0:00:17.289    - onPause()@8737978:30
[main (2)                                ] INFO     - 0:00:17.290    - removed listener: 3 listeners
[main (2)                                ] INFO     - 0:00:17.307    - removed listener: 2 listeners
[main (2)                                ] INFO     - 0:00:17.308    - removed listener: 1 listeners
[main (2)                                ] INFO     - 0:00:17.310    - removeListener (context: com.bubblesoft.android.bubbleupnp.MainTabActivity@8737978)
[main (2)                                ] INFO     - 0:00:17.312    - removed listener: 0 listeners
[main (2)                                ] INFO     - 0:00:17.345    - onStop()@8737978:30
[main (2)                                ] INFO     - 0:00:18.370    - ACTION_SCREEN_OFF
[main (2)                                ] SEVERE   - 0:00:18.376    - watchdog: enabled
[cling-36 (1390)                         ] WARNING  - 0:00:22.789    - .j                          : Client connection was aborted: d.e.b.a.a.r0.f: Connect to 169.254.11.101:63445 timed out: http://169.254.11.101:63445/upnp/xml/devices/MediaRenderer1.xml
[cling-36 (1390)                         ] WARNING  - 0:00:22.790    - .f                          : Device descriptor retrieval failed, no response: http://169.254.11.101:63445/upnp/xml/devices/MediaRenderer1.xml
[main (2)                                ] INFO     - 0:00:31.798    - performDeviceSearch: search done
[main (2)                                ] SEVERE   - 0:00:31.799    - watchdog: device search--: 2
[main (2)                                ] INFO     - 0:03:46.855    - ACTION_SCREEN_ON
[main (2)                                ] SEVERE   - 0:03:46.856    - watchdog: disabled
[main (2)                                ] INFO     - 0:03:47.860    - onRouteRemoved 6a32de1ac50b3437fccbab086dd1dea6 => MediaRouter.RouteInfo{ uniqueId=com.google.android.gms/.cast.media.CastMediaRouteProviderService:6a32de1ac50b3437fccbab086dd1dea6, name=SHIELD, description=SHIELD Android TV, iconUri=null, enabled=true, connecting=false, connectionState=0, canDisconnect=false, playbackType=1, playbackStream=-1, deviceType=1, volumeHandling=0, volume=0, volumeMax=20, presentationDisplayId=-1, extras=Bundle[{com.google.android.gms.cast.EXTRA_CAST_DEVICE="SHIELD" (6a32de1ac50b3437fccbab086dd1dea6)}], settingsIntent=null, providerPackageName=com.google.android.gms }
[main (2)                                ] INFO     - 0:03:47.861    - not removing cast device due to recent screen on or off
[main (2)                                ] INFO     - 0:03:48.113    - onRestart()@8737978:30
[main (2)                                ] INFO     - 0:03:48.118    - onStart()@8737978:30
[main (2)                                ] INFO     - 0:03:48.121    - onResume()@8737978:30
[main (2)                                ] INFO     - 0:03:48.123    - registered media button event receiver
[main (2)                                ] INFO     - 0:03:48.124    - added listener: 1 listeners
[main (2)                                ] INFO     - 0:03:48.127    - added listener: 2 listeners
[main (2)                                ] INFO     - 0:03:48.129    - source changed: Playlist
[main (2)                                ] INFO     - 0:03:48.130    - selected item changed: Shine On You Crazy Diamond (Parts I-V)
[main (2)                                ] INFO     - 0:03:48.136    - setSeekBarDetailsText: FLAC • 44.1 kHz • 16 bits • Stereo • Vol 13
[main (2)                                ] INFO     - 0:03:48.139    - setSeekBarDetailsText: FLAC • 44.1 kHz • 16 bits • Stereo • Vol 13
[main (2)                                ] INFO     - 0:03:48.140    - setSeekBarDetailsText: FLAC • 44.1 kHz • 16 bits • Stereo • Vol 13
[main (2)                                ] INFO     - 0:03:48.146    - added listener: 3 listeners
[qtp179090117-1493 (1493)                ] SEVERE   - 0:03:48.152    - watchdog: Jetty request++: 3
[main (2)                                ] INFO     - 0:03:48.152    - added listener: 4 listeners
[qtp179090117-1493 (1493)                ] WARNING  - 0:03:48.153    - no current decode info found for item key: c228e5fc-a1f9-ff3f-0000-000010e3498d_F628113
[main (2)                                ] INFO     - 0:03:48.154    - addListener (context: com.bubblesoft.android.bubbleupnp.MainTabActivity@8737978)
[qtp179090117-1493 (1493)                ] SEVERE   - 0:03:48.157    - watchdog: Jetty request--: 2
[main (2)                                ] INFO     - 0:03:50.392    - onRouteAdded 6a32de1ac50b3437fccbab086dd1dea6 => MediaRouter.RouteInfo{ uniqueId=com.google.android.gms/.cast.media.CastMediaRouteProviderService:6a32de1ac50b3437fccbab086dd1dea6, name=SHIELD, description=SHIELD Android TV, iconUri=null, enabled=true, connecting=false, connectionState=0, canDisconnect=false, playbackType=1, playbackStream=-1, deviceType=1, volumeHandling=0, volume=0, volumeMax=20, presentationDisplayId=-1, extras=Bundle[{com.google.android.gms.cast.EXTRA_CAST_DEVICE="SHIELD" (6a32de1ac50b3437fccbab086dd1dea6)}], settingsIntent=null, providerPackageName=com.google.android.gms }
[main (2)                                ] INFO     - 0:03:50.392    - not adding already added cast device
[main (2)                                ] INFO     - 0:03:52.306    - onPause()@8737978:30
[main (2)                                ] INFO     - 0:03:52.307    - removed listener: 3 listeners
[main (2)                                ] INFO     - 0:03:52.309    - removed listener: 2 listeners
[main (2)                                ] INFO     - 0:03:52.310    - removed listener: 1 listeners
[main (2)                                ] INFO     - 0:03:52.311    - removeListener (context: com.bubblesoft.android.bubbleupnp.MainTabActivity@8737978)
[main (2)                                ] INFO     - 0:03:52.312    - removed listener: 0 listeners
[main (2)                                ] INFO     - 0:03:52.341    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.342    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.343    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.344    - onServiceDisconnected
[main (2)                                ] INFO     - 0:03:52.357    - onDestroy: start
[main (2)                                ] INFO     - 0:03:52.414    - .n                          : AndroidUpnpService.onDestroy() took: 57 ms
rec head would you happen to have multiple servers running MC by chance? I did notice an instance where I had MC running media network on multiple devices (PC, Pi, etc.) where if I disabled media network on the PC while music was playing on a phone from the Pi, it'd instantly stop. Might be a coincidence but you never know. Wish there was an easier way to log/document all this stuff.

I looked over the log and capture you sent. There isn't anything too obvious in there OTHER than the second interface that also shows up above (169.254.11.101 which is one of those self-assigned nets). The comment above is interesting regarding playback stopping when you disable media network on a second PC. That sends a bunch of unsubscribe from events and bye-byes but it's connected to the IP of the PC being disabled.

I guess I'd want to know why you have a second interface with a unassigned IP and what the playback device is in your logs. (Pi -> MO4??)
Thanks!

[Awesome Donkey]

That's... a good question. Time to go fishing.

[bob]

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.
Reverting back to 25.0.80 should fix it or wait for the next build when it will be greatly increased.

[rec head]

Thanks Bob.

I haven't really used a remote today so haven't come across the stop in the middle problem. I did just repeat my issue of not being able to connect at all, moving the mouse on the server computer and then being able to connect. AFAIK all power saving features are off. Screen saver is on but starts at 5 minutes and I don't have the problem at the 5:01 mark.

Any other settings that could be causing this?

[RoderickGI]

An update:
Both my Workstation and HTPC (which hasn't shown the issue) were on Windows 10 1803. I allowed the HTPC to be updated to 1903 because Microsoft was nagging me. I had to update my video driver to the last version that supports 3D to get video playback to work after that, and then did some 3D setup, which sort of worked. So, some changes in MC.

The HTPC now has the same problem. Gizmo wouldn't connect to it this morning. I ran PingTools and then Gizmo connected. So the above points to it being an OS problem, but what part of that update might have caused the issue, I have no idea.
EDIT: With further testing Gizmo is now connecting to the HTPC, so maybe the HTPC just took too long to wake up the first time. I shall test it further to see if the problem does consistently exist on the HTPC.

Interestingly Gizmo still wouldn't connect to the Workstation after the PingTools run above. But after a second run of PingTools it connected.

FYI I do run Media Network on both the HTPC and Workstation, but the HTPC often is asleep when I see this problem with the Workstation. Gizmo wakes the HTPC even if it won't connect.


I have been wondering about all the extra network interfaces, and whether they are contributing to the issue. For example, I have two physical ethernet ports with only one connected, two Hyper-V interfaces to match the physical ethernet ports, an Ncap Loopback adapter installed with Wireshark, a TAP-Windows Adapter, and either WAN Miniports.

The physical ethernet port that isn't connected has an IP Address of 169.254.153.193/16. So maybe that answers this question about Awesome Donkey's additional interface.

I guess I'd want to know why you have a second interface with a unassigned IP and what the playback device is in your logs. (Pi -> MO4??)

I just checked the connecivity of Gizmo to my Workstation and the HTPC again, after typing the above. Neither connected again. So the issue is definitely some sort of timeout problem. The time is measured in minutes, and not seconds or hours. It sort of sounds like a Network discovery, SSDP, UPnP, or similar problem. But the Wireshark log I sent showing a failure to connect clearly shows that the phone contacted the server on port 52199, the server responded, and then the phone resent the connection attempt.

AndrewFG, I shall PM you the Wireshark logs... or maybe I won't. It seems I can't attach files to a PM. Doh! Sent to you via email, using the address the DMRA uses.

[RoderickGI]

BTW, I just;

Started MC
Started Wireshark, logging stopped
Cleared the MC log
Started logging in Wireshark
Tried to connect Gizmo to the MC Server on my Workstation, which failed
Stopped Wireshark log
Reported problem in MC logging


The Wireshark log looked the same as my earlier testing
The MC Log was didn't have anything obvious in it. In fact, the IP Address of my phone was not mentioned at all. Log attached.

[RoderickGI]

Okay, I repeated the above test sequence, but this time ran PingTools instead of trying to connect with Gizmo.

The Wireshark log show PingTools requesting the DeviceDescription on port 52100, 52101, 52102, 52103, and 52199, which corresponds to the open ports associated with MC.

The MC log has seven records mentioning my phone address, 192.168.0.11. Five are the GET transactions above in Wireshark, and the other two are M-SEARCH transactions with what I believe is the SSDP default broadcast IP Address, http://239.255.255.250:1900*  Log attached.

EDIT: The PingTools GET transaction does show up in the MC "Services & Plug-ins > Media Network" page for my Workstation Library Server. It does not when Gizmo fails to connect.

Does this information help?
What else might help track this down?

[RoderickGI]

I ran the test sequence above one more time. This time I ran PingTools and then ran Gizmo, which successfully connected to my Workstation MC Server.

There are 26 references to the phone IP Address, 192.168.0.11, in the MC log. First the PingTools "port scanning" process, and then a normal Gizmo connection, starting with a GET...Alive http call. So the sequence is;

   Line 245: 0018484: 14468: Sharing Plugins: CHTTPListenerWorker::HandleRequest: UDP: 192.168.0.11: M-SEARCH: http://239.255.255.250:1900*
   Line 248: 0018656: 2144: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10/DeviceDescription.xml
   Line 252: 0018718: 3148: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10/DeviceDescription.xml
   Line 256: 0018765: 5484: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10/DeviceDescription.xml
   Line 261: 0018796: 12892: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10/DeviceDescription.xml
   Line 269: 0018812: 10524: Sharing Plugins: CHTTPListenerWorker::HandleRequest: UDP: 192.168.0.11: M-SEARCH: http://239.255.255.250:1900*
   Line 271: 0018812: 9176: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10/DeviceDescription.xml
   Line 585: 0039062: 2840: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10:52199/MCWS/v1/Alive
   Line 591: 0039078: 2840: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10:52199/MCWS/v1/Authenticate
   Line 596: 0039125: 2840: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10:52199/MCWS/v1/Playback/Zones?Token=n9JMQyW0
   Line 614: 0039250: 2840: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.0.11: GET: http://192.168.0.10:52199/MCWS/v1/Browse/Children?Skip=1&ID=-1&Token=n9JMQyW0

That is all for now. Log attached.

[bob]

Try adding a string value to the registry (Without MC running):

HKCU->Software->J River->Media Center 25->DLNA
called
Bind Only To
Set the string value to
1.2.3.4
where 1.2.3.4 is replaced with your main ethernet interface IP address.

When you startup MC now you should only see that one interface in the Media Network Status window.

Report results please.

[RoderickGI]

Okay, I added the Bind Only To setting to the Registry, as per that attached image. I assumed that you meant me to add a new String Value, rather than a Key with a string value set in it.

The "Active Interface" row in the MC "Services & Plug-ins > Media Network" page then only showed the IP Address of the hardware ethernet port on my Workstation. BTW, I disabled the second hardware port and the two Hyper-V ports on the Workstation earlier, with no effect.

I then tested using the same method as above.

The Wireshark log was unchanged, with TCP Retransmission showing the phone wasn't seeing the [SYN ACK] response from the Workstation.

The MC Log showed no record of the phone IP Address, 192.168.0.11. It did show several "Socket bind success" records for the Server IP, on port 52100. Log attached.

[wer]

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.

[RoderickGI]

Okay, it seems like the two issues, playback stopping unexpectedly and not being able to connect from a Client App on an Android phone to a MC Server, are separate issues and not related, or at least not having the same cause.

While Rec Head started this thread, I am definitely having the same problem. Initially on my Workstation, but after a Windows update to 1903 on my HTPC, it looked like the same thing started happening with that server as well. Now I'm not so sure. I think it may still be working on the HTPC and I just saw one failure due to a delay while the PC was woken. EDIT: Yes, Gizmo is still connecting to the HTPC just fine.

As my Wireshark logs seemed to show that the phone contacted the Server, and the Server responded, but the phone didn't see the response, I bit the bullet and removed Norton Security from my phone and rebooted it. I had already removed Norton Security from my Workstation.

I then went back and tamed the hell out of Windows Defender, again, putting in Exclusions for everything sensible. I also opened up the firewall completely using the Windows Defender Firewall with Advanced Security App. Of course I have rebooted the PC multiple times.

I also added the "Bind Only To" registry setting to have my Workstation MC Server bind only to the network interface of my ethernet IP Address. The Server in MC shows that only that interface is active.

Nothing has worked. If Gizmo hasn't been used for a while, a period I have yet to determine, but it is measured in minutes, then Gizmo on the phone will not connect to the Workstation MC Server.

Running PingTools first will always enable Gizmo to connect immediately afterwards.
I also own a copy of JRiver "Bingo SSDP" (one of the few who bought it, I suspect) and running that first also enables Gizmo to connect.


I could try to compare Wireshark logs from my Workstation with logs from mt HTPC, but that will take a bit of work. I have already noticed that the HTPC doesn't show the GET...DeviceDescription record in the MC "Services & Plug-ins > Media Network" page, even when it works. On the Workstation the connection doesn't work unless I have recently seen this record.

The only other thing I can try is to find an equivalent of Wireshark on Android, and try to see if the phone sees the response from the MC Server or not. If the phone does see the response then it would seem that Gizmo does not... but Gizmo hasn't been updated in years, so it seems unlikely one part of it suddenly stopped working, doesn't it? Also MO4Media, Panel, and Tremote also fail when Gizmo doesn't work, so this must be a MC Server or network, or security issue. I have done my best to eliminate any security software issue, and the network works fine once PingTools/Bingo SSDP has been run. So that leaves something unusual about the server.

[Scobie]

Is something knocking the port out? Another (older) instance of MC installed? Is it possible to try a non standard MC port?

[RoderickGI]

No other MC instances running on the Workstation, but there is one on the HTPC using the same port. Trying another port is a good idea. But why did it always used to work, and then just stopped?

I am just on to something with the Access Key lookup though, so I will try another port after finishing that.

Thanks.

[RoderickGI]

Typed as I tested stuff, so just a stream of thoughts and observations.

Okay here was a strange observation.

I started Gizmo, it tried to connect to the last MC Server is connected to, my Workstation, and failed.
I switched to trying to connect to my HTPC, which was asleep. As soon as the HTPC started to wake, I cancelled the connection.
I then tried to connect to my Workstation again, and it worked. Just like when I run Pingtools/Bingo SSDP, starting another application allowed Gizmo to connect.

Then I noticed on the HTPC, in the MC "Services & Plug-ins > Media Network" page, that the only record which MC received from my phone, IP Address 192.168.0.11, was a GET...Alive call to a resource on my Public IP Address, and not the internal LAN IP Address. I have port forwarding set up from my Public IP Address to the HTPC, so maybe that is why the HTPC is still connecting?

I turned off Mobile Data on my phone, waited about 25 minutes, and repeated the above process. However, the connection to my HTPC was so fast that I couldn't cancel it. The result was that Gizmo connected to the HTPC. The first record show in MC was again a GET...Alive call, and this time it was to the local IP Address. When I then tried to connect to my Workstation it didn't work.

So I turned Mobile Data back on and tested again.
Alas, the behaviour wasn't repeatable. In fact connecting to the HTPC seems to be faster now. Maybe it is trying the local IP Address first and getting a connection, while in the past it tried the Public IP Address first?

Regardless, Gizmo will connect to the HTPC just fine, but won't connect to my Workstation.

So I tried changing the Workstation MC Server port to 55000. I checked that the JRiver web site had the new port and tried the connection. Gizmo did try to use the new port. Same result though: failed.

I ran Bingo SSDP to see if that would make Gizmo work. Nope. It seems that Bingo SSDP is hardcoded to use port 52199, as the Workstation Library Server didn't show up in it. EDIT: Nope. The firewall blocked port 55000.

So I ran PingTools to see if that still worked. Nope. A scan of the services on my Workstation didn't show up the MC Library Server. I would conclude that the MC Library Server isn't advertising itself, in that case. I may be wrong, but that is what it looks like, and that could possibly explain the whole issue. But then I haven't opened port 55000 in the firewall. Hmmmm...

The HTPC could see the Workstation Server, but couldn't connect to it. Once it failed to connect the HTPC dropped the Workstation from its list of available servers under Playing Now... and added the three DLNA Servers that the Workstation runs to its list. So the HTPC was using cached information which it updated once the connection failed. It looks more like the Workstation isn't advertising its MC Server. But I see SSDP NOTIFY and M-SEARCH transactions from the Workstation both on itself and on the HTPC, even GET calls from my TV to the Workstation, so maybe not.

I changed the Workstation Server port back to 52199. Gizmo still wouldn't connect.
Bingo SSDP then showed the Workstation Library Server again.
Gizmo then connected to the Workstation.

I tried port 52150, which is within the port range I have open on the firewall, for inbound and outbound TCP and UDP packets.
Surprise, that worked. But, Gizmo tried to connect to the HTPC first and I cancelled that. So maybe I was seeing an instance of what occurred above in the third paragraph. So I will have to wait and test again later, once whatever it is has timed out...

... Okay, using port 52150 didn't work either. The Pingtools fix did make it work though. Bingo SSDP also saw the Workstation Library Server as well, so I guess it looks in the port range 52100 to 52200 ( or 52199).



So, querying port 52199 wakes the connection and allows Gizmo to connect.

That is pretty much me done. I don't have any other ideas. Well, I could install Package Sniffer https://play.google.com/store/apps/details?id=com.packagesniffer.frtparlak on my phone and see what comes through I guess. But a little more direction would be good. What to look for, really?

[rec head]

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.

I think you missed the part about me not knowing about networking. You have to break that down a few more steps for me.

Since I'm not the only one with this going on but I know the least about how to fix it I think I'm just going to upload more tracks to Google Play or use the server on my NAS for a while.

RoderickGI if there is anything you want me to try just let me know. I'll be following the thread. And like I said above, keep it at monkey level.

[RoderickGI]

Don't worry about the Ping idea. I have been using Wireshark to see what is happening. It is a very detailed network monitoring tool. The problem occurs even when the network connection is up and running, and I am monitoring it. Ping was a good idea if the network card was going to sleep, but it isn't in my case.

I can't think of anything to ask you to try. If I think I find a solution, I may ask you to try it. I suspect the issue is MC installation specific and related to MC Settings in the Windows Registry. Not stuff I know much about. It is not specific to a Library, but the PC.

Most of my brain dump above is in the hope that Bob or someone else from JRiver knows what I have tested, and might come up with something else to test.

What you could tell me is;
Do you have multiple Zones set up on this MC Sever of yours?
Do you have multiple DLNA Servers on this MC Sever of yours?

If the answer is no to both the above, have you had multiples of either in the past, but deleted them? For example, when playing with Zoneswitch or DLNA functionality?

Since I'm not the only one with this going on but I know the least about how to fix it I think I'm just going to upload more tracks to Google Play or use the server on my NAS for a while.

Running PingTools first does make this problem go away, and it is a free App so a no-cost solution, other than being extremely annoying. You said that worked for you. Once I have Gizmo/MO 4Media/Panel playing it will keep working. It is only once I leave the Client I am using stopped for some time, or closed (I haven't tested that bit in detail) that it all stops working.


JRiver: Bingo SSDP just took half a dozen or so refreshes before it found either of my HTPC or Workstation MC Servers, even though both were running. Something isn't right there.

[Awesome Donkey]

Even with 25.0.86 I still have issues with streaming to remotes (JRemote, Panel, MO 4Media, etc.) where it randomly stops playing on my phone.

So I decided to test another, older phone which always worked (running Android 7 Nougat) and... it works fine. Tried my test album multiple times and it never fails to play, so that pretty much tells me the issue is with the phone itself. Not sure if it has a flaky Wi-Fi chip, if Android 9 Pie's battery optimization feature(s) are messing with it (I have battery optimization disabled for remotes + tried fully disabling Doze via adb) or if it's something else altogether.

[rec head]

So I decided to test another, older phone which always worked (running Android 7 Nougat) and... it works fine. Tried my test album multiple times and it never fails to play, so that pretty much tells me the issue is with the phone itself. Not sure if it has a flaky Wi-Fi chip, if Android 9 Pie's battery optimization feature(s) are messing with it (I have battery optimization disabled for remotes + tried fully disabling Doze via adb) or if it's something else altogether.

Seems like several different things going on here. When I can't connect with my phone I also can't connect with a wired client on the same network.

What you could tell me is;
Do you have multiple Zones set up on this MC Sever of yours?
Do you have multiple DLNA Servers on this MC Sever of yours?

On my HTPC with the problem:
1) I do have multiple zones setup. They are set to switch to bitstream when I play an Atmos title and back to PCM for everything else. Then there are renderers like my AVR that show up in zones.

2) On previous versions of MC I had tried different servers trying to get a Roku to see and play video. They have since been deleted. I have no idea when I deleted them. Now under Options->Media Network-> ... Add or configure DLNA servers ... it only lists a Generic DLNA. AFAIK it is set to defaults


Are we all using Windows 10 on our servers?

[bob]

This is a very complicated thread.

Checking BingoSSDP, the port that it's using for Panel is NOT hardcoded to 52199. It obtains the port from the URL base from the DeviceDescription.xml which has the correct port in it.

If you are seeing 52199 I wonder if there is a server instance of MC (maybe 24) running in the background?
You might try running Device Spy from the UPnP tools for Developer package to see what the network looks like.
http://www.meshcommander.com/upnptools

It sounds to me like the WOL packet isn't getting to the right place somehow.

This version of Windows doesn't have Mac address randomization enabled does it? I'm not even aware if Windows supports this feature.

[RoderickGI]

Sorry Bob, I sent you on a tangent there.

Bingo SSDP didn't see the server because I used a port outside the range I had opened for MC use. So the firewall was blocking port 55000. I did edit the thread above to add a note on that before I originally posted, but I guess that got lost in all my words. I have bolded that edit now.  Bingo SSDP worked on port 52150. which was an open port.

It is a complicated thread because it is an opaque problem. I can't seem to get a grip on what the issue is, as I just don't have enough knowledge.

No other instance of MC running. Just MC25 on the HTPC and my Workstation. No randomised MAC addresses.

WOL packets always get to where they need to go, and wake either PC successfully. This was shown in the Wireshark logs I sent you. But the interesting and probably important records in the log of a failed connection were these:

Code: [Select]

37 1.866998 192.168.0.11 192.168.0.10 TCP 52199 6c:f0:49:ef:0c:93 41297 74 41297 → 52199 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4374222 TSecr=0 WS=256 ***Gizmo calls to Server***
38 1.867090 192.168.0.10 192.168.0.11 TCP 41297 84:c7:ea:3b:4f:39 52199 66 52199 → 41297 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460 WS=1 SACK_PERM=1 ***Server answers Gizmo***
...
41 2.873887 192.168.0.11 192.168.0.10 TCP 52199 6c:f0:49:ef:0c:93 41297 74 [TCP Retransmission] 41297 → 52199 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4374322 TSecr=0 WS=256 ***Gizmo repeats call to server, having not seen reply***
...
48 3.905399 192.168.0.11 192.168.0.10 TCP 52199 6c:f0:49:ef:0c:93 41301 74 41301 → 52199 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4374425 TSecr=0 WS=256 ***Gizmo tries a call using a different port***
49 3.905502 192.168.0.10 192.168.0.11 TCP 41301 84:c7:ea:3b:4f:39 52199 66 52199 → 41301 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460 WS=1 SACK_PERM=1 ***Server answers Gizmo on second port***
...
52 4.868076 192.168.0.10 192.168.0.11 TCP 41297 84:c7:ea:3b:4f:39 52199 66 [TCP Retransmission] 52199 → 41297 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460 WS=1 SACK_PERM=1 ***Server repeats answer on original port***
53 4.920588 192.168.0.11 192.168.0.10 TCP 52199 6c:f0:49:ef:0c:93 41301 74 [TCP Retransmission] 41301 → 52199 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4374526 TSecr=0 WS=256 ***Gizmo repeats call to server on second port, having not seen reply***
...
263 22.869731 192.168.0.10 192.168.0.11 TCP 41297 84:c7:ea:3b:4f:39 52199 54 52199 → 41297 [RST] Seq=1 Win=0 Len=0 ***Server resets connection on original port***
...
271 24.907743 192.168.0.10 192.168.0.11 TCP 41301 84:c7:ea:3b:4f:39 52199 54 52199 → 41301 [RST] Seq=1 Win=0 Len=0 ***Server resets connection on second port***

That process continues for some time as you can see. 21 seconds or so. I'm no expert on reading Wireshark, but I think my observations at the end of the log lines are correct.

What I have been trying to determine is, why does Gizmo on the phone not see the reply from the server?
Why does running Bingo SSDP or Pingtools enable Gizmo to see the replies shortly afterwards?

[RoderickGI]

Specifically, the communication sequence started in frame 37 by Gizmo, acknowledged by the server in frame 38, never receives an [ACK] back from Gizmo. Such a frame would look something like this one from a successful connection:

Code: [Select]

30 6.702236 192.168.0.11 192.168.0.10 TCP 52199 6c:f0:49:ef:0c:93 39368 60 39368 → 52199 [ACK] Seq=1 Ack=1 Win=87808 Len=0
I can't see anything special about the successful [ACK] frame from the successful connection.  ? It is just another TCP packet, like the first two frames in the sequence. Same protocols, correct ports and devices. It would be highly unlikely that the same [ACK] packet was always malformed, and therefore blocked, in the failed connection sequence. Particularly as connection works after using Bingo SSDP or PingTools.

Soooo, Microsoft Message Analyzer, it looks like we are going to become acquainted... Actually, I can just turn Dropped Packet Logging in the Group Policy Editor. 

[RoderickGI]

Well, the only packets Windows Defender Firewall is reporting that it is dropping are not related to this problem, I think.

• There were a bunch of broadcast WOL packets, which actually should not be blocked, but WOL works anyway, and Wireshark shows the packets. So I don't know why they are reported as being dropped, unless Wireshark is reporting dropped packets as well. I might have to look into that. Or maybe they were broadcast at some other device with a different MAC address. Hmmm, yeah that would be right.
• There a couple of Targeted WOL packets, but again they may have been for a different MAC Address, so were dropped.
• There were lots of mDNS packets, sent to an IP Address I don't know about. They could be Bonjour / mDNS requests, which multicasts packets to IP address 224.0.0.251 and port 5353. I still have iTunes and Bonjour installed on this PC. But they look like Chromecast broadcasts actually. Anyway, they are Multicast DNS packets

Felds:          date            time       action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
   Line 569: 2019-08-02 13:08:29 DROP UDP 192.168.0.11 255.255.255.255 37521 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 570: 2019-08-02 13:08:29 DROP UDP 192.168.0.11 255.255.255.255 40638 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 571: 2019-08-02 13:08:29 DROP UDP 192.168.0.11 255.255.255.255 48384 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 572: 2019-08-02 13:08:29 DROP UDP 192.168.0.11 255.255.255.255 39731 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 573: 2019-08-02 13:08:29 DROP UDP 192.168.0.11 255.255.255.255 49318 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 574: 2019-08-02 13:08:29 DROP UDP 192.168.0.11 255.255.255.255 43679 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 575: 2019-08-02 13:08:30 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 576: 2019-08-02 13:08:30 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 585: 2019-08-02 13:08:31 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 586: 2019-08-02 13:08:31 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 593: 2019-08-02 13:08:35 DROP UDP 192.168.0.11 192.168.0.10 49962 9 130 - - - - - - - RECEIVE                     Note: Targeted WOL packet to port 9
   Line 594: 2019-08-02 13:08:35 DROP UDP 192.168.0.11 255.255.255.255 44232 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 611: 2019-08-02 13:08:51 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 612: 2019-08-02 13:08:51 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 619: 2019-08-02 13:09:11 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 858: 2019-08-02 13:14:39 DROP UDP 192.168.0.11 192.168.0.10 38699 9 130 - - - - - - - RECEIVE                     Note: Targeted WOL packet to port 9
   Line 859: 2019-08-02 13:14:39 DROP UDP 192.168.0.11 255.255.255.255 48392 9 130 - - - - - - - RECEIVE                     Note: Broadcast WOL packet to port 9
   Line 863: 2019-08-02 13:14:57 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet
   Line 864: 2019-08-02 13:14:57 DROP UDP 192.168.0.11 224.0.0.251 5353 5353 122 - - - - - - - RECEIVE                     Note: Google mDNS packet



So, no joy there. It looks like packets from Gizmo on the phone are not being dropped by the Windows Defender Firewall.

Which only leaves the required [ACK] being blocked at the source; the Android Phone. On an outbound TCP packet. That generally just isn't done.

Well, my router could be blocking packets. But it doesn't report it is (no surprise), and why would a router block TCP packets between two devices on a Private network? Plus, if I run Bingo SSDP on the phone first, Gizmo always connects, and stays connected as long as I am using it. But if I close Gizmo, after an undefined period it won't connect to the server again.

[RoderickGI]

BTW Bob, I did try Device Spy.

It didn't seem to show much more than Bingo SSDP. What I did notice though was that Gizmo didn't appear in either Device Spy or Bingo SSDP even when it was playing media. My TV does appear in both as a DLNA Renderer. So why wouldn't gizmo appear?

But Panel also doesn't work when this issue exists, so it wouldn't be a UPnP/DLNA issue, would it? It seems to be a TCP networking issue.

[bob]

BTW Bob, I did try Device Spy.

It didn't seem to show much more than Bingo SSDP. What I did notice though was that Gizmo didn't appear in either Device Spy or Bingo SSDP even when it was playing media. My TV does appear in both as a DLNA Renderer. So why wouldn't gizmo appear?

But Panel also doesn't work when this issue exists, so it wouldn't be a UPnP/DLNA issue, would it? It seems to be a TCP networking issue.

Gizmo (JRemote, etc) don't use SSDP so they won't show up in Device Spy. Bingo only uses it for discovery, it has no visible services so it won't show up either.
Device Sniffer should show the flow with Bingo.
I agree it seems to be a TCP networking issue.
Could you possibly test a different router or perhaps disable IPV6 on your router/windows machine? Is it possible the phone is using IPV6 on your LAN??

[RoderickGI]

Could you possibly test a different router or perhaps disable IPV6 on your router/windows machine? Is it possible the phone is using IPV6 on your LAN??

Thanks for replying and the Good questions Bob.

Yes, I have another router and I could try using that for a short time. Also, I can turn off IPv6 in the router, so I'll try that first.
My current router is fully IPv6 aware, and seems to use both IPv4 and IPv6 wherever it can. My phone does show up in Wireshark using IPv4 though. I'll see if I can work out what my phone is using internally. I may even have IPv6 turned on in the Workstation NIC, but not in the HTPC. I shall check.

Remember though that Gizmo connects successfully to my HTPC MC Server and is on the same router and wireless network. Although since updating to Windows Build 1903, and with all this testing, it has become a bit slower connecting and a little less reliable. It took about four attempts just now to get Gizmo to connect, even though I had just rebooted the HTPC. But MC had stopped responding on the HTPC overnight, so that could have had some influence.

I had a look at Device Sniffer, but it seemed to do that same thing I can do with Wireshark, but with a bit less detail. Yes, Wireshark and Device Sniffer showed Bingo SSDP doing its thing on port 1900, and the MC Media Network logs show it as well.

But Device Sniffer does seem to show IPv6 traffic more clearly. I'll have a bit more of a look at that and see what I can learn. Reading IPv6 traffic is way harder than reading IPv4 traffic!