Print

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

[nusihb]

Hi, I posted this earlier in the MC24 subforum, but I think it belongs here (and have since upgraded to MC25).

The problem is, using MC 25, either via Media Center or Media server, songs stop playing and you have to hit 'play' again, sometimes after 2-3 songs, sometimes longer.

Oppo 105D is used as the 'DLNA render', from a PC with Windows 10 1809 over ethernet. Uncompressed Wav files are used, sent unchanged.
The Oppo and the PC is connected to the same Gb switch (Netgear GS108T).

There is 3 options what I can see if you right-click on the Oppo (in Media center), but it doesn't make any difference if they are checked or not.

Music is ripped via dBPoweramp CD Ripper (to uncompressed Wav files).   

Please help - this is driving me a little bonkers

[JimH]

AndrewFG has a program to analyze your Renderer.

You could try toggling the option for SetNextAVTransport.

[nusihb]

Thanks for the prompt answer.!
But, I can't 'unset' that option, it 'checks itself' every time I start the play list. If I stop and uncheck it, it's back as soon as I start the play list again.

How do I get hold of the analyze program?

Thanks

[AndrewFG]

^
Please download the DMRA from my sig, run the tests against your renderer, and post the renderer report here.

[nusihb]

Thanks!
Do you want me to run one test file in the format I use (16-bit/44100 wav), or others as well?

[nusihb]

Render report from test attached. Wav 16/44100/2 used.

Thanks for the help!

[nusihb]

About the 'SetNextAVTransport' setting, for the Oppo 105 it can't be turned off (unchecked). Once next song starts, it's checked again.
On my second system (in a different location) which has a Oppo 205, this can be 'unchecked' and it stays off.

But for both systems, the render report lists DLNA settings that are not turned on, and vice versa for the 105 (says it's turned off when it isn't).

In any case, if we could get the setting for 'SetNextAVTransport' to stick (unchecked) for the Oppo 105, it may solve the problem with interrupted play lists?

   

[JimH]

It's a mouth full, but it's "renderer", not "render".

[AndrewFG]

The DMRA report shows clearly that the Oppo renderer does NOT support SetNext.. — so you need to disable SetNext support in MC.

I think you are saying that you tried disabling SetNext in MC, but that this setting is not sticky?? I don’t know how that can be the case, but if it is indeed so, then the problem is in MC..

[RoderickGI]

I think it was the other way around Andrew.

MC was continuously checking the setting "Disable SetNext support (for broken renderers)" because the Oppo 105 does not support SetNext.

Nusihb kept trying to uncheck the setting, and MC just checked it again when it tested the renderer.

[nusihb]

I think it was the other way around Andrew.

MC was continuously checking the setting "Disable SetNext support (for broken renderers)" because the Oppo 105 does not support SetNext.

Nusihb kept trying to uncheck the setting, and MC just checked it again when it tested the renderer.

Yes, that's correct.
My Oppo 205 does not support SetNext either according to the renderer report, but here the 'uncheck' setting 'sticks'.
Doesn't really matter though, since I have no problem with playlists on the Oppo 205 system.

It's the Oppo 105 system that stops after 2-3 songs.

[bob]

Yes, that's correct.
My Oppo 205 does not support SetNext either according to the renderer report, but here the 'uncheck' setting 'sticks'.
Doesn't really matter though, since I have no problem with playlists on the Oppo 205 system.

It's the Oppo 105 system that stops after 2-3 songs.

I've been looking to get a 105 for home, no success for what I want to pay yet!

The SetNext will check disable by itself if the renderer doesn't support the command at all.
Not sure what you issue is, you could try disabling transport events in that controller options area.

[nusihb]

To get back to this, I've tried every DLNA option combination I can think of.

I saw some threads about something that changed about DLNA in MC24, so I tried with MC23.
And it worked! No interruptions of playlists!

So, what changed in MC24 that can have a impact on this?
Can it be fixed?

[bob]

To get back to this, I've tried every DLNA option combination I can think of.

I saw some threads about something that changed about DLNA in MC24, so I tried with MC23.
And it worked! No interruptions of playlists!

So, what changed in MC24 that can have a impact on this?
Can it be fixed?

Most likely it's the detection that MC24 and newer does to see if another controller has taken over the device.
This is done by seeing if the state changes (from Play to Stop) while it's supposed to be playing.
It could be that your device is reporting improper state at some point during playback.

Would you start playback, turn on logging and when the stop occurs either submit the log via the logging dialog box or attach it here.
Thanks.

[nusihb]

Most likely it's the detection that MC24 and newer does to see if another controller has taken over the device.
This is done by seeing if the state changes (from Play to Stop) while it's supposed to be playing.
It could be that your device is reporting improper state at some point during playback.

Would start playback, turn on logging and when the stop occurs either submit the log via the logging dialog box or attach it here.
Thanks.

Thanks.
Where in MC25 do I turn on logging?

[nusihb]

Thanks.
Where in MC25 do I turn on logging?

Never mind - I found it.
Search is your best friend... as usual.
I will try to capture a log.

[nusihb]

Hi again, it took awhile, but now I have a log where the playlist stops, this time after the first song even.
For some reason it almost seems that it works better with the log turned on - there's a lot fewer interrupts after turning the log on.
I have it set to auto reset at 5MB file size.

Song is 'loaded' at row 1056688: 4832 in the log, error is visible at 1057266: 7448, and 1062813: 4832.

Thanks for looking into this!

[bob]

Are you on the current build (25.0.74)?

There is something weird going on with the device. I see this:

Code: [Select]

1067828: 4832: General: CDLNADeviceServiceCaller::CallServiceFunction: DLNA function call failed or timeout! url = http://192.168.1.122:2870/control/AVTransport function = SetAVTransportURI execution time = 7 ms of 6000 ms.
7 ms execution means it rejected the SetAVTransportURI (which sends the metadata to the renderer in advance of the play command, like it's in a broken state or doesn't like the file.

The next one is actually worse:

Code: [Select]

1073906: 4832: General: CDLNADeviceServiceCaller::CallServiceFunction: DLNA function call failed or timeout! url = http://192.168.1.122:2870/control/AVTransport function = Stop execution time = 6037 ms of 6000 ms.
That means it timed out on a stop command (6 seconds!!)

It kind of looks like the renderer is in a broken state.
Perhaps your playlist includes a file it can't handle (too high of a bitdepth/sample rate/format) and that confuses it.
Power cycling the renderer in the case usually clears it up.

You might try enabling the bitrate option in the DLNA server advanced section, that gives renderers that can understand it more info.

What is the Audio Output format in your DLNA server Audio configuration?

[nusihb]

Hi, yes on current build.
Files played are all 16-bit/44khz/1411kbps wav files ripped from CD via dBPoweramp CD ripper (uncompressed wav).
DLNA Server Audio output is set to 'original'.

Most of the times it works, but randomly stops between songs. If you hit 'play' again on JRemote (or on MC) it'll continue w/o any issues (until it randomly stops again).

But it does work w/o any issues when using MC23, so something happened after that... and it seems to work better when the logging function is turned on (on MC25), so maybe it['s a timing issue?

[RalphBrooks]

Was an effective solution to the issue initially reported by nusihb ever found?  My system is experiencing the exact same symptoms of random stopping when play all is selected for a playlist or entire music library.  My DLNA device is a Primare BD32 MKII, which is basically an OPPO BD-105 with greatly enhanced audio quality.  I started seeing this issue starting with release 24 thru the latest version of 26 (not tried version 27 yet).  Did not and do not see this issue running release 23.  Sometimes it will play only one song and stop or sometimes it may play many songs, but it always stops and some point.  I have searched the database and found other reports of similar sequential DLNA playback issues with OPPO BDP-105, but again no solution noted. 

[RoderickGI]

G'Day Ralph.

Run AndrewFG's Whitebear Digital Media Renderer Analyser to see what your Renderer is capable of. See Reply#3.

DLNA can be a little fragile. If you are trying to play Gapless and have unchecked the "Disable SetNext support (for broken renderers)" setting, and MC keeps setting it, that can cause issues. Confirm whether your Renderer supports SetNext, and what else it supports.

A lot has changed from MC23 to MC27 in terms of DLNA, in an effort to better handle non-complying Renderers. You could look through the Release Notes in the Wiki to see if anything obvious changed in MC24 that changed behaviour. You could also download MC27 and run it in trial mode to see if it fixes the issue.

[RalphBrooks]

Roderick,
Thanks for the quick response.  I have now tested with latest release 27, but the symptom is still present (in limited runs this evening and it played anywhere from 1 to 12 songs), but it still just stops randomly at the end of a song and doesn't start a new song.

I did run the Digital Media Renderer Analyser and attached those test results, but it didn't provide me any further insights.  As I noted, my player is a Primare BD32 MKII which is based off the OPPO BDP-105 design, a multi-channel universal player. My music files are in FLAC format, stored on a Synology NAS, hardwired over Ethernet with JRiver running on an Intel NUC running the latest Win10 (64-bit) OS.  I am not attempting to play gapless as the UPnP software used in the OPPO/Primare does not support the needed commands [AVT:SetNextAVTransportURI (gapless play)=NOT Supported, AVT:SyncPlay (synchronous play)=NOT Supported] as noted in both my log file as well as the log file from user nusish for his OPPO-105 who initially reported this symptom.  Also the DLNA Controller Option "Disable SetNet Support (for broken rendereres)" is checked and I'm attempting to override that configuration.

I have also repeated the stopping at the end of a song symptom running JRiver on a Win10 laptop using the same DLNA over NAS/Primare/LAN hardware.

I did captured and attached a JRiver log file for a run where only one song played and stopped.  Perhaps I can get someone to review this and provide some insight into what might by causing this very frustrating symptom.  It appears to me my issues started with DLNA changes starting with release 24 (it's not obvious what it might have been from looking thru the version release notes).  I'd hate to find the answer is there is no solution and I can't get an entire albums let along playlists to play non-stop without constantly hitting the next button.  I love JRiver and playing music on my Primare MD32-MKII via DLNA provides sound quality that is considered one of the best you can get using a universal media player (and was priced accordingly!).   

Thanks, Ralph

[RoderickGI]

I'm no expert at reading MC logs, but I had a look anyway.

Have you made any changes to the DLNA Server in MC, or are you just using the Default DLNA Server just as it came when MC was installed/upgraded?

For example, are you playing the flac files in "Original Format"? It appears that they are being transcoded in the log.
Are you applying any DSP to the files before sending to the Primare MD32-MKII? Or more importantly, do you need to or want to? If not, you should set the DLNA Server to send audio in Original format. But even if you are transcoding, applying DSP, and sending the audio as "PCM L16 No header" (basically WAV format), the tracks should continue to play.

There is a problem in the MC log with the Primare MD32-MKII not providing position data correctly:
0013328: 4360: Playback: CPlayerZoneDisplayInfo::UpdateFileInfo: Zone {BD32MK2} Playback state is PLAYING but GetPosition is returning 0. Estimated = 1250, Returned = 0

MC says it is "ignoring GetPosition failure" and seems to be estimating the playback position, so maybe that isn't a problem. But playback never gets to the last second of the track, by the look. It looks like MC is stuck on the last second for nearly 80 seconds in the log, one second short of the 202 second long track.

There is a setting in the "DLNA Controller Options" to "Ignore Get Position Failure (for broken renederers)". You should tick that setting and see if the problem goes away.

If that doesn't work you should try ticking the other settings in "DLNA Controller Options", one at a time, and see if any fix the problem. Particularly the "Ignore Transport Events (use polling mode)".

That is all I can see in the log just now. I can see the play thread being cancelled, but it isn't clear why. I think your Primare MD32-MKII wasn't responding correctly, so MC got stuck. After it cancels the play thread it looks like it opens the connection to the Primare MD32-MKII again. But I'm not sure what all that means.



BTW the IP Address of your Primare MD32-MKII seems to be 192.168.1.253, which is a little unusual, as that is at the end of the IP Address assignments available to a DHCP Server on your Router, normally. Is there any reason that you have the IP Address set up there? It shouldn't cause issues, it is just a little strange.

[RalphBrooks]

Thanks for your input and time, interesting insights and pointed me to what appears to be the "solution".

Resolution was not what I expected and I’m feeling a little stupid for not previously trying all the other DLNA Control Options addressing broken renderer options, I have lived with this issue now for several years.  It was the "Ignore Transport Events (use poling mode)" that appears to have resolved my issue.  Not clear to me how this resolves the issue, but it’s clear the problem is with the Renderer.  I now wonder if this is unique to my specific Primare BD32 MKII , Primare's BD32-MKII implementation based on the OPPO 105 design or if this same "fix" would resolve similar DLNA/stop-playing-at end-off-song issues I've seen posted from other OPPO BD-105 users.  I still have both an OPPO BDP-105 and BDP-103 players from prior stereo hardware configurations. For my piece of mind and curiosity when I have a chance I'll connect those systems back up and see what happens and report back.  As both OPPO and Primare have both stopped development/support for their universal players I’m very happy JRiver has implemented workarounds for players like these with DLNA implementation issues (which will never be addressed) such that users can still effectively utilize JRiver and playing via DLNA on those devices.

The specific failure symptom is that when the song reaches the end of the track you can see it's still playing (based on position indicator at the top of the screen in standard view), stuck at or repeating the last second of the song.  I tried checking the "Ignore Get Position Failure (for broken renderers)" and it still failed.  When it got stuck at the end a song I then checked the "Ignore Transport Events (use poling mode)" in the DLNA Control Options and immediately saw JRiver jump to the next song without me clicking on next and it's been working ever since. 

And thanks for the heads up on the transcoding point.  Long ago when I initially configured JRiver for DLNA support I recall setting it for playing in original format.  However, somewhere over the years with upgrades and playing with different configurations I changed it to PCM-24 bit and missed configuring it back to original format.

BTW, the IP address of 102.168.1.253 just happens to be what the router (Asus RT-N66U) happens to dynamically assigns, I have not set it to a specific IP.

Thank you again for your support.  This forum is outstanding and has been invaluable to me over the years such that this is the first time I've ever needed to post for help in resolving an issue using JRiver.

[RoderickGI]

Excellent result Ralph. Thanks for the feedback.

I think this fix would also work with Oppo 105's showing the same problem. It is probably why the setting exists! I'm not so sure with the 103, but probably. I think the Oppo 205 resolved the issue, but I'm not sure.

I didn't actually search the forum for this issue with the Oppo 105, but I've read a lot of threads sharing problems with the Oppo DLNA implementation. I'm sure there are one or two threads that came to the same resolution.

[AndrewFG]

^
Ralph, my own (unmodified) 105 does not suffer from the problem that you report, so I would be interested to see what the DMRA has to say about your modified unit. So can you please download the DMRA from my sig, and post the renderer report here?

[RalphBrooks]

I ran it earlier and it was attached in one of my earlier responses, but I've attached it again.  Interesting you are not experiencing the same issue, but I've found feedback in other threads of a similar symptom from other OPPO-105 users.  Let me know if you see anything interesting or if I need can run some specific test configurations to be of use.

[AndrewFG]

Ralph, thank you for posting the renderer report.

The two event subscription lines (below) indicate that Event Subscriptions and Notifications are working properly. So it should NOT be necessary for you to set Ignore Transport Events (AVT:Events) in MC.

Code: [Select]

AVT:Event Subscription=Succeeded
RC:Event Subscription=Succeeded

So the event notifications are proven to be getting through to the DMRA but not to MC. Are these two applications on the same PC? If not then you may have a routing issue that blocks incoming traffic to the MC PC. Or if they are on the same PC then there is probably a firewall or a/v software that is blocking incoming traffic to the MC application.

[RalphBrooks]

Thanks Andrew for your continue input, much appreciated.

I ran your DMRA application on the same Win10 based Intel NUC that is running JRiver Media Center as both the digital controller and media server.  Only other devices involved are a NAS for hosting the music files and the Primare BD32-MKII as the player/DLNA renderer, all connected via hardwired Ethernet.  Since the NUC is dedicated as my Home Theater PC there are no other applications running other than Windows and Norton 360.

Based on your additional insight I tried disabling the Firewall and antivirus in Norton and unset the Ignore Transport Events (AVT:Events) in MC for the Primare DLNA Contorl Options.  I then started a playlist and within a couple of songs again experienced the same behavior of hanging on the last second of a song. 

Next experiment, I uninstalled Norton completely, rebooted and disabled Windows Firewall on the NUC.  I again unset the Ignore Transport Events (AVT:Events) in MC for the Primare DLNA Control Options and ran a playlist again.  Same result, still "fails".  Multiple tests and sometime MC stops played on last second of the first song and some times it's after a few songs.

I also run task manager to ensure there were no other applications of questionable processes running that would be obvious candidates for interference.  Looked at performance levels and CPU, memory and ethernet usage all within reasonable level except for the added network traffic caused when MC is stuck at the end of a song.

I don't believe there is, but perhaps there is some configuration in my router (Asus RT-N66U) that could be impacting this behaving where the status change response from the Primare as the Player/Renderer's is not reaching the MC running on the NUC.  I've looked over all the set-up/configuration options and nothing jumped out at me.

Tried all configuration changes I can think of so far.  I get how it appears to be a communication blockage/interference between the Renderer (Primeare) and MC on the NUC, but I'll be darned if I can find it yet.  For now I can at least enjoy playlists and entire albums without manual intervention by continuing to use the polling mode work-around (set Ignore Transport Events (AVT:Events) in MC) with it's inherent higher network chatter created when I wan t to enjoy music on HTPC utilizing JRiver MC.

BTW - I worked at Intel for 32 years in their systems group on all forms of PC's and truly appreciate how complex, challenging and frustrating some of these problems can be to resolve.  Again, thanks for your continued support in this forum.     

[RoderickGI]

I have an issue with my ISP provider supplied router blocking certain UPnP/DLNA packets when it shouldn't, particularly for LAN traffic. I can make that issue disappear instantly by turning off the firewall in the router. You might try doing the same with your Asus RT-N66U. Naturally, protect your network from external intrusions while you run that test and don't leave the firewall turned off.

If that fixes the problem then you know where to look further.

I use Norton 360 and find it very manageable and more reliable than, for example, Microsoft Defender. I tested my issue with Norton 360 off and completely uninstalled, and it made no difference. Norton 360 seems to handle MC processes quite well. I don't think it is the cause of any issues in my environment, currently. It has only caused one issue with MC in seven years of use, and that was just a bad update, and fixed quickly.


As you sound pretty technically literate and capable, if you want to get down to the cause, I think the next step is to start running Wireshark on your LAN and track the communications when a track works, and when it fails, and see what might be missing during the failure. That could take a bit of work though, and generate a lot of data to sort through.



Andrew I overlooked these two results:

Code: [Select]

AVT:Event Subscription=Succeeded
RC:Event Subscription=Succeeded


Because I basically assumed that that were testing the start of playback. i.e. Subscription to the (start of) the playback event, and not subscription to the end of playback. I guess an event is an event though, and Start and Stop/End are both events.

What exactly is being tested for those two results?

The "Play test" does test the whole Start-Play-Finish cycle though, so at least for the DRMA the Renderer is doing everything correctly.

I guess the question is: If those two tests succeed, does that mean that all Events should succeed?

[RalphBrooks]

Well that was an interesting insight concerning router and ISP firewall.  Sure enough, when I disable my router firewall and unset the Ignore Transport Events (AVT:Events) in MC for the Primare DLNA Control Options my issue of stopping at the end of a song does not occur!  However I did find, at least for my router (ASUS RT-N66U) I had to disable the firewall for both IPV4 and IPV6, disabling either of them separately did not resolve the issue.

I also went back and re-tested MC version 24 and again could not reproduce this issue, but I can reproduce it starting with release 25.

I figure I'm up the the challenge and (with all my retirement free time and cooler /wet winter weather coming on) I'll give Wireshark a try.  Never too old to learn something new   I was more of a PC hardware than network guy in my career at Intel, but I have several friends who are network experts that I can consult if needed as I attempt to gather further insight into my specific failure mechanism.  I will also set-up my "old" OPPO BD-105 and give it a try, but I fully expect it to demonstrate this issue as well.

Oh the joys of technology...

[wer]

I'll just chime in to say that you might want to double check your firewall rules and configuration... Because if you have a router that is filtering traffic on the switched LAN ports when the firewall is configured to only be active on the WAN port, then you should get a new router. That is an unforgivable crime.

Depending on how your router software works (if the firewall is active globally), it might be fixable by inserting as the highest priority rule to allow all from all local addresses to all local addresses.

[RoderickGI]

Because if you have a router that is filtering traffic on the switched LAN ports when the firewall is configured to only be active on the WAN port, then you should get a new router. That is an unforgivable crime.

  Sad face, because this makes me sad. My ISP router has very little configurability of the firewall. Basically, Port Forwarding, On or Off. It does have Custom rules, but there is no reference to LAN or WAN, and it isn't even clear if the rules block traffic or allow it. Others have tried to work that out and failed. I also can't delete the default rules, or change their order. Very sad. I need a better router, but the ISP one support my landline and failover to Mobile Broadband, so I can't use a simple router. 


Hopefully yours is a better router Ralph. It sounds like you are making progress though. 

[wer]

Rod, it grieves me to hear that you are saddled with such a p.o.s.  Since I have hurt your feelings, if you will start a new thread with the appropriate screenshots and your router specs, I will be glad to give it some consideration.

[bob]

You might want to get a dumb switch and connect the lan ethernet cables to that and just connect that to the router. That would let you keep the firewall in place and eliminate any filtering between machines on the Lan.

[wer]

That will work around the problem for any devices that aren't wifi.

[bob]

That will work around the problem for any devices that aren't wifi.

Yeah, another router in lan only mode would fix that and turning off the wifi on the main unit, it's kind of an odd coincidence but I'm in the process of doing something very similar on my home office system for a different reason.

[wer]

Yes, but I'd rather see if it can be made to work properly first, before sending him to buy extra devices.

[RalphBrooks]

Since my system "works" when I disable my router firewall this indicates in my case the router is blocking a response packet from the renderer (Primare BD-32 MKII) to JRiver MC running on the NUC PC, but not every time.  Failures maybe at the end of the first song or after several songs are played.  My understanding is that the router may be doing this because it views the packet as abnormal.

As further experiments, I updated the router FW, a new version was released in June, but failure mechanism was still exhibited after this change.
I also tried setting the router firewall option "Respond ICMP Echo (ping) Request from WAN" to yes, but this also had no effect.
I see no other setup options that would allow me to set my router to ignore (not prevent) packet modification on the LAN side.

As a different experiment I wanted to minimize the LAN configuration.  The NUC and renderer are already connected on the same switch, but the NAS is on a different SW connected to the router.  So I loaded/played music files only on the NUC SSD and powered off the NAS to take it completely out of the picture.  Still experienced the same failure, JRiver stopping after a song completed (waiting for rendered response that it's done playing the song), sometime on the first song and sometime after a few songs.

My next steps will be to install Wireshark on the NUC and capture logs of both passing and failing scenarios and look for what information is being blocked and perhaps understand what the router is seeing and why it's blocking the renderer response packet.

[wer]

Ralph, it doesn't make sense that your router firewall can block packets between the renderer and the nuc when those devices are connected to the same switch that is not the router.

There are IDS's that can respond to and interfere wih broadcast traffic, but I do not think the software on that Asus router is that sophisticated.

[RalphBrooks]

OK, any theory's idea why turning off the router firewall eliminates the failure mechanism.  I went down that path on the experience/recommendation of Roderick who has seen similar behavior.  I was surprised as well, as I believed most consumer routers (like my router from Asus) are actually a switch for the LAN ports, which is then connected to the routing hardware which sits between this switch and the WAN port, so the router can't control routing of packets that are directed to another computer within the LAN.  However, the test results indict otherwise!

[JimH]

Did you try getting help from your ISP?

[wer]

Yes, I can formulate several theories but I prefer to work from data. Unplug the switch from your router, and test again.  Yes the nuc won't have Internet access for a while but that's not important.  Test repeatedly to establish whether or not the results are intermittent or not.  You had said before it happened "sometimes".

[AndrewFG]

Because I basically assumed that that were testing the start of playback. i.e. Subscription to the (start of) the playback event, and not subscription to the end of playback. I guess an event is an event though, and Start and Stop/End are both events.

What exactly is being tested for those two results?

AVT (Transport) Subscriptions are the mechanism whereby the Renderer informs the Control Point about changes (Events) in the Transport state (e.g Play, Pause, Stop, track Position, etc.).

RC (Renderer Control) Subscriptions are the mechanism whereby the Renderer informs the Control Point about changes (Events) in the Renderer state (e.g. Volume, Mute, etc.)

[AndrewFG]

Just so that everybody understands what is going on:

1) The majority of UPNP commands are based on the SOAP protocol. Under this, the Control Point (client) initiates a communication socket to the Renderer (server), issues a command, to the server and receives a response from the server. This is very similar to a web browser page fetch transaction. And therefore most firewalls and a/v software are designed to handle it. And indeed that is working in your case.

2) The Event Subscription / Notification is different. In this case the Renderer (Server) initiates a communication socket to the Control Point (client), and sends a message to it. This is the complete opposite of a browser web page fetch. And many firewalls and a/v software do not handle this well. Indeed they treat it as an external attack from the Renderer on the Control Point. This seems to be your case.

Furthermore:  You mention that the router may be the cause. As a general rule a router applies a “stateful” firewall that controls traffic between LAN and WAN. But again, as a general rule, a router does not control traffic within the LAN (i.e. it just acts as a switch rather than as a router). So if you think the router is at fault, then a) it would be interesting to know your WAN / LAN topology, and b) rather than buying a new router, it might be simpler and cheaper to subsume the Ethernet connection between Control Point and Renderer to a subsidiary Ethernet switch.

[RoderickGI]

Thanks Andrew.

I learn more and more about DLNA every time you post. I did notice that SOAP encoding was being used when we discussed SetNext recently. Interesting.

[wer]

b) rather than buying a new router, it might be simpler and cheaper to subsume the Ethernet connection between Control Point and Renderer to a subsidiary Ethernet switch.

He said he tried that and it still happened.  See my comments above. I want to see more specific testing.

[RoderickGI]

I went down that path on the experience/recommendation of Roderick who has seen similar behavior.

I would be more comfortable if that was called an observation rather than a recommendation. But I guess I did recommend testing with the firewall off.

I will work with Will to do some separate diagnosis on my router, but for those here, I have another observation.

When I use my Android phone running Gizmo to try to connect to a MC Server running on my Workstation it fails.
If I then run either PingTools or Bingo SSDP (the JRiver tool) on the phone, then try Gizmo again it succeeds.
If I keep using Gizmo it continues to work. If I close it for a while, and then try to use it again within a few minutes, it connects successfully.
If I close Gizmo for more than a few minutes, maybe ten, then again it will fail.

My conclusion from this so far is that a temporary record is being created in the router ARP Table by running PingTools or Bingo SSDP. That record is maintained while it is in use, but then purged after a few minutes if it is not used.

The interesting thing with the above? Gizmo will connect to the MC Server on my HTPC first time, every time. Well, as long as I haven't been messing with the network and a lot of software. Let's say failures are extremely rare. I can remember one.

Networking is such fun.
BTW, using a switch might be a solution, although it means running another device, power, etc. I guess a router in bridged mode, so operating as a switch would also work.
Using another router has issues such as keeping the DHCP Server on one device, so all wired and wireless devices are on the same network segment. Also I don't want Double NAT with using two routers. Plus I want to use my landline and Mobile Broadband failover provided by the ISP router.
But I'll discuss all that in a separate thread.

[RoderickGI]

2) The Event Subscription / Notification is different. In this case the Renderer (Server) initiates a communication socket to the Control Point (client), and sends a message to it. This is the complete opposite of a browser web page fetch. And many firewalls and a/v software do not handle this well. Indeed they treat it as an external attack from the Renderer on the Control Point. This seems to be your case.

This is what I thought was being blocked at my Workstation PC by the local software firewall. But removing the Norton 360 firewall and antivirus completely and taming the Microsoft Defender firewall on the Workstation still had the same result. Failure to connect.

While turning off the router firewall fixe the issue immediately. Hence, I am blaming the router.

[RalphBrooks]

Did you try getting help from your ISP?

No, Comcast is our ISP provider and our service is provided via cable as no fiber optics available at our house location yet
(Cable modem is an Arris Surf board SB6190 connected to the Asus RT-N66U router)

My experience (first hand) with attempting Comcast help in resolving a router issue causing a service down was well (I'll be kind), it was poor.  I've worked with many technical service groups in my electronics engineering career and know that first line "technical" support would be very unlikely to even grasp this issue let alone be useful. Second line support after spending several hours with them might be of help, but I was hoping the brain trust offered via forum would be a much better first approach to devise tests, review results and propose possible failure mechanisms and potential resolutions.  If needed or of value I can and would seek Comcast technical support, but I'm not convinced it's warranted yet.