OnlineVideos 1.9.0.0 [2014/09/7] (1 Viewer)

[offbyone]

The manage site screen is empty because of the http error in the logs. Same goes for the update. No info from server = nothing to update. Copying the dlls manually will work for the moment but be outdated in a few days again, once any dev updates a site.
Do you have a poxy configured in IE, use any VPN services, tried with firewall turned off, ... I don't know what the cause is on your PC, all I can say is that the same OV install work on my (and most other people's PCs - otherwise there would have been a lot more reports).

 

[Ministerk]

It might be miss configuration of the windows firewall for the mediaportal process, (I think) you can choose LAN access only, to be able to connect to the internet it needs wan access. Look in your firewall settings for the mediaportal process.

 

[Herr R aus B]

Brief update on the issue...

I had a second MP client running MP 1.6 and OV 1.8.0 and everything worked a treat (especially the ARD Mediathek stuff in question). The OV DLLs are dated march 2nd 2014. I upgraded that client to MP 1.8 and OV 1.8.0 was reported being incompatible. So I udated OV to 1.8.1 and ARD Mediathek is screwed again. So far there is NO updating of the OV DLLs taking place - they are dated April 17th 2014. When I take the OV 1.8.0 DLLs from .\plugins\windows\OnlineVideos everything is fine again - except the "Sites verwalten" screen, which works on the second client I just updated still wouldn't work on the client that first had these issues.

So the problem seems to be reproducable and might be deducted to that internal auto update which doesn't seem to get the proper files downloaded.

As for the networking problems you assumed: As I said, I can open that web service page in several browsers without any problems. This would then also be the by far one and only URL I am having problems to connect to from my network - rather unlikely, don't you think?

I checked me network setup anyways - no domain or address blocking so everything should work fine... Entirely switching off the windows firewall doesn'
t help neither...

I would really like to get this problem sorted out. I also offer you testing support because it wouldn't be fair not to support ppl who offer great free sw products. So if you for exanple had a test stand alone client for those web services, I could test the download stuff from different machines outside MP.

If that'd be helpful for you, just tell me - private note will be OK as well... I already did that together with a guy in Finnland when it was about getting a Zalman case VFD to run with MP 0.something... darn long ago ;-)

Regards

Axel

 

[offbyone]

If you consider that it works without problems on thousands of other user's PCs, it is highly unlikely that the code is wrong, but way more likely that something in your windows or MP setup/configuration is wrong or different to everyone else's.
This also means that I cannot tell you what is wrong. How should I? I cannot reproduce the problem. This is as far as my possible support goes.

Maybe try removing other plugins in MP first, only leaving OV, to eliminate the problem that other plugins configure networking in .net framework for MP wrong.

 

[Herr R aus B]

Well - I scratched everything except WIN7 - I de-insralled everything .NET framework included. re-installed everything and still the same problem... as it runs well on two other machines here I think you're right - must be that particular machine and the last way might be re-instylling the OS... I should stay with linux instead... this windows stuff drives me nuts...I don't get it...

Thanks for the efforts anyways...

Regards

Axel

 

[Herr R aus B]

It doesn't leave me...

I looked up, what that HTTP 417 status means. It says, that the client expected something from the server, that the server can't deliver. This then means, that there can't be a general networking problem at my side, because this status message is delivered by the server - i.e.: my client is connected to this service and thus, the network should be working. Otherwise the web service call shouldn't be throwing that exception, as it would never get the appropriate response or status from the (in that hypothetical case not connected) server.

Some sources point out, that this should be a status message that shoudn't appear usually (well - usually...) and that its most likely cause is a a preceeding "100 continue" expectation. They write, that this might be caused by proxies filtering certain header information in the http requests rsp. responses. The solution pointed out is not to use this kind of expectation then - which can be achieved by setting appropriate configurations (i guess for the underlying SOAP framework or whatever).

If the URL you gave me really is an indicator for a corrupted network connection, then the network connection can't be the problem, as I can reach that URL clearely and especially from the machine on which MP rsp. OV has this problem. I'd rather assume, there is a SOAP related problem of any kind or something with the SOAP framework or .NET framework or whatever underlying layer used by MP and OV. Even more likely, as I copied all the working DLLs from the other machine, where everything works...

The point is: up to MP 1.8, which enforced tha update to OV 1.8.1 there was no such problem. The real puzzling thing is, that it is just this one machine - which - even more confusing - is one of the cleanest installations here, because it just contains WIN7, DX9, .NET 4.5, LAV and MP + addons... no firewall, no adblocker, no antivirus, no nothing, that could interfere with whatever network connection... :-(

So - hoping not to annoy you too much - if you had a stand alone test client, that calls all this SOAP services seperately, that might be helpful for further investigation. I was looking at it using a network monitor, but having such a test client would easy up identifying the proper packages immensely...

nd one last thing to mention - all DLLs - also on the machine, that doesnt have this update http status 417 bla problem - are dated from april. None of them is from june...

Well...

So far so good.

Regards...

 

[doskabouter]

well, one thing that's reasonably simple is check network traffic with fiddler2.
If you do that on the "working" machine, you can save the request and retry that request at the "non working" machine.

 

[Ministerk]

well, one thing that's reasonably simple is check network traffic with fiddler2.
If you do that on the "working" machine, you can save the request and retry that request at the "non working" machine.

You could also compare the requests from different machines and see if something differs.

 

[TheBatfink]

Hi. I am seeing several dump files (currently 4) with the name 'MPUrlSourceSplitter DATE TIME' which are individually in excess of 1GB each in my MePo log folder.

Are these files OV related? Seems like they shouldn't be there, they are obviously huge files. I'm attaching logs but I haven't cleaned them out for a while so apologies if they are painful to go through.

If it isn't OV generating them, where should I direct the question do you think? Log files taking 4GB can't be by design I'm sure.

Also, the reason I spotted them was I had just had another no active protocol error on youtube. I backed out of OV and then attempted to go back in and MePo froze. So it would be good if you have any comment on the protocol error and the crash?

Thanks!

EDIT: Name of the dump files incase it helps identify the event recorded in the logs that created them..

2014-07-22-18-57-44-911
2014-07-19-00-15-30-499
2014-07-12-09-05-28-012
2014-07-14-19-03-26-153

 

[georgius]

These dump files are probably from OV crash, when you played some video. The crash means that whole MP is closed and you're returned to Windows. Freeze shouldn't generate such dump files, but sometimes I noticed that some skins (e.g. default Titan skin or StreamedMP skin) are generating system exceptions which are lately catched and MP continues in its work. This behaviour can be noticed by freeze (approx. 20 - 30 seconds, it depends on how much data should be dumped and also it depends on speed of your drive - in SSD case it is much more faster). So, you can delete them.

No active protocol is returned, when there is no protocol implementation to handle spoecified URL. As I can see in your logs, it was HTTPS. To current OV filter, it's not planned to be added, maybe to new merged filter.