Problem with dual function device

[zip]

If it was a access control issue in Serviio, you'd see the message in the log. We don't see that, so it's something else.

From what I know, devices sometimes show access control errors, even though the problem is not really related to it - it could really be anything.

My thinking is it's due to Serviio only supporting one device per IP, so if there are multiple devices coming from the same IP, they get mixed up, resulting in the error message.

[DaFerociousBeast]

Why is Serviio the only DLNA server having this problem? That's the issue.

The HP MediaSmart Connect is a Windows Media Center Extender, which uses a whole different protocol (RDP), to connect to my PC. So that should cancel itself out automatically.

The HP MediaSmart Connect is also a DLNA Client, which is a different protocol of it's own. How can Serviio not differentiate between the two separate protocols?

There has to be something wrong in the way Serviio implements the DLNA communication standard. The HP MediaSmart is DLNA Certified too.

Very hard to except when: Windows Media Player=works
Plex=works
KooRaRoo=works
Mezzmo=works
Serviio=does not work!

Could you give a crack at using the Mezzmo profile I uploaded to make a Serviio profile for the HP MediaSmart Connect, because Mezzmo gave the same error with the generic DLNA profile also. I checked if it had a profile for the HP MediaSmart Connect, and it did. As soon as I changed the profile, it worked instantly.

[DaFerociousBeast]

Ok, I'm not using the free version, so support should be better than this.

It isn't a device issue. It's a Serviio issue, with it not playing well with the device.

Other DLNA server software works fine.

At this point I feel cheated, I supported this software by paying for it, but now support doesn't want to put the effort into fixing this problem.

Really now?!?!

At least attempt to write a profile. I did upload one that works with another DLNA server.

[zip]

As I said, it's not a profile issue, but probably something in the way Serviio implements them. In any way, Serviio doesn't support multi IP clients.

I currently don't have the resources to work on a fix for one device, sorry. It might get fixed in the future as a part of other work.

If you want refund, send email to sales.

[DaFerociousBeast]

It's really not about a refund. It's just that things don't make sense.

DLNA is DLNA.

Serviio is solid, simple, and not resource heavy. Before I had this problem, I was in limbo between 2 DLNA server softwares, and picked Serviio.

I like to support smaller upstarts/companys...I'm all about simplicity and innovation. I'd hate to switch teams. It just gets frustrating when another program that provides the same function works. Kind of like having to switch web browsers because a page won't function correctly, they're both functionaly doing the same task, but one doesn't like how things run.

[DaFerociousBeast]

Reaching...Please take a look.

http://download.java.net/jdk7/archive/b ... ernal=true

http://stackoverflow.com/questions/1430 ... ess-return

http://stackoverflow.com/questions/1369 ... ction-fail

[DaFerociousBeast]

Same problem, and the person just gave up.

viewtopic.php?f=13&t=10741&start=20

[DenyAll]

Have been monitoring this and your other related topic: viewtopic.php?f=5&t=16494#p90186. As zip stated above this will not be resolved by changing the profile. Nor do I believe it was related to the Panasonic issue you refer to, but that's neither here nor there.

If I understand the issue, I think this is more to do with how devices advertise their presence on a network than with DLNA per se. In a normal scenario (in simple terms) a device periodically sends a "hello" message to all servers. The server then registers the device as a client. With your device, I suspect it is sending [at least] two "hello" messages on the same IP address - one for its DLNA client service and one for its Windows Extender client service. Serviio is receiving these and registering only one of these clients (in this case the wrong one). The only way to fix this is in code - if my guess is correct, then Serviio must filter out the messages from non-relevant client services - and zip has already commented on the issue with doing this in support of one device at this stage.

Of course, I am only speculating on the cause of the issue. It may be able to be confirmed by looking at the "hello" packets (using wireshark or similar). This may also help in any future fix.

[DaFerociousBeast]

Thank you, you put my thoughts into better words.
I'll give wireshark a crack later this weekend.
I just don't see how the other servers can differentiate, shouldn't Serviio be able to tell the difference between DLNA/UPnP & RDP (which is how extenders connect to WMC)?

I always thought it was a coding issue, but Mezzmo acted the same, until I switched the device profile, so maybe they found a way around the issue in the profile. I posted the Mezzmo profile, have a look and see if anything relevent to device communication sticks out. I'm all eyes n ears!

[DenyAll]

shouldn't Serviio be able to tell the difference between DLNA/UPnP & RDP (which is how extenders connect to WMC)?

I believe (could be wrong) that they both use SSDP for device discovery. You can also use Device Sniffer (part of the UPNP Developer tools) to see what is happening.

I looked at the Mezzmo profile - at first I thought it may be matching on device UID as it contains a line:

<guid>59B127CB-C54E-4956-AA4D-146E9661254B</guid>

but that UID doesn't seem to match any of yours, so I'm not sure (but maybe also look for this UID in the packets).... In any case, Serviio doesn't use UID for device detection so it wouldn't help.

[DaFerociousBeast]

Have NOOOO idea what I am looking for or even have to do in Wireshark.

Could you let me know what I should be running/testing, and how do I post the results here.

A lot of things going on when I hit start.

Thanks.

[DenyAll]

I know what you mean... I'm not a wireshark expert, it's a matter of playing.

In Wireshark, set your Capture Options, Capture Filter and IP Address - set the filter string to "host " and the IP address of your device. Press Start.

Once running, start your device. Let it run for 30 seconds or more to capture some meaningful data and then you can stop it (Capture, Stop). You should see packets between your device and server - look at your SSDP packets. In the middle pane, expand the "Hypertext Transfer Protocol" - this will allow you to see into the packet. You are looking for ssdp discover packets - hopefully you will find two sets, one defining the DLNA characteristics and one the Media Extender's. Also look for SSDP packets that have those two UID's embedded (plus that one from the Mezzmo profile) - may provide a hint as to how to distinguish the two. If you find something that you think may be of value, save your captured data and post the file here.

If you're using Device Sniffer (may be easier to understand) then set your Network Filter to view IP4 only. Look for M-SEARCH packets coming from your device. See if there is a difference in the ones from the DLNA app vs those from the Media Extender.

[DaFerociousBeast]

Using device sniffer, I get nothing with IPV4 filter.

I only get one M-SEARCH (Repeats itself over and over) on one port for the device IP, with IPV4 & IPV6 filter.

Wireshark only shows the uuid of the DLNA side of the device, nothing at all for the uuid of the WMCE side.

Any ideas?

[DenyAll]

No not really. Try broadening (lessening) your filters and seeing if that produces any more packets. Its probably a matter of playing with it, or you could just post a dump from wireshark with no filters here (showing your renderer device starting up) and maybe one of the experts can assist.

[DaFerociousBeast]

Way beyond my knowledge, and problem shouldn't be occurring.

Thanks to any who tried.

I give up!!

[DaFerociousBeast]

Interesting!?

viewtopic.php?f=6&t=4134

Authorization Problem!!!

Fix Fix Fix!!!