INTERACT FORUM
More => Old Versions => JRiver Media Center 25 for Windows => Topic started by: rec head on July 08, 2019, 06:29:32 pm
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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
-
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
-
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.
-
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.
-
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?
-
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.
-
Please send to bob at jriver and copy matt. Thanks.
-
Done.
-
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.
-
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.
-
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.
-
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:
[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.
-
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.
-
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.
-
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.
-
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.
-
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 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.
-
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:
[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!
-
That's... a good question. Time to go fishing.
-
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.
-
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?
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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" (https://play.google.com/store/apps/details?id=com.jriver.bingossdp&hl=en_AU) (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.
-
Is something knocking the port out? Another (older) instance of MC installed? Is it possible to try a non standard MC port?
-
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.
-
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, 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.
-
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.
-
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.
-
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?
-
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.
-
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:
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?
-
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:
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. 8)
-
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 (https://en.wikipedia.org/wiki/Multicast_address)
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.
-
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.
-
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??
-
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!
-
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.
-
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?
-
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?
-
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.
-
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.
-
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!
-
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.
-
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?
-
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.
-
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".
-
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.
-
Good information. Thanks.
Are the files local? If not, could you test with files located on the Pi's memory?
-
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?
-
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. :)
-
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.
-
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??
-
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.
-
Maybe it's lost its connection with the sound device.
-
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...
-
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.
-
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.
-
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! :D
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! :D
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.
-
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! :D
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! :D
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. >:(
-
Yikes, hopefully it's not affected, but you never know.
-
Yikes, hopefully it's not affected, but you never know.
It will be if it's truly a buster kernel or stock package bug.
-
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
-
Flash?
-
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?
-
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.
-
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.
-
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. :)
-
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!!
-
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! :D
-
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!
-
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.
-
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.
-
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?
-
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.
-
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.