[goblygoop]

too big for pastebin

http://owenconnection.com/stuff/ServerWMC.log
http://owenconnection.com/stuff/log-2014....00.33.zip

[scarecrow420]

Hey goblygoop, it doesnt look like the right logging options have been used. You need to enable LogReplyMessages in the config file, it seems like you have enabled a different debug option that logs every GUID header in the streams which produces huge logs but they arent useful for this thread topic as i need to see the contents of replies sent back to the client (to see if it the server sent back a skip position to the 2nd client).

Please turn off the stream/GUID header logging, then edit the config.xml file in notepad and set LogReplyMessages to true

[goblygoop]

http://owenconnection.com/stuff/log-2014....50.47.zip
http://owenconnection.com/stuff/ServerWMC.log

did i get it right this time?

[scarecrow420]

http://owenconnection.com/stuff/log-2014....50.47.zip
http://owenconnection.com/stuff/ServerWMC.log

did i get it right this time?

The server log is right.

Here is where first client starts a live stream

Code:

2014/01/08 07:38:52.095    Received client request: 192.168.1.155|OpenLiveStream|38110|0|125|DJCH/125
2014/01/08 07:38:55.580    OpenLiveStream Reply 01/04: smb://sean:*******@CRAY/Recorded TV2/TempXBMC/LiveTV_192.168.1.155_Digital Cable_125_2014_01_08_07_38_52.ts
2014/01/08 07:38:55.580    OpenLiveStream Reply 02/04: smb://sean:*******@CRAY/Recorded TV2/TempXBMC/LiveTV_192.168.1.155_Digital Cable_125_2014_01_08_07_38_52.ts
2014/01/08 07:38:55.580    OpenLiveStream Reply 03/04: -1
2014/01/08 07:38:55.580    OpenLiveStream Reply 04/04: <EOF>
2014/01/08 07:38:55.580    Finished request OpenLiveStream in 3.48s

Note the -1 in reply line 3, indicating this is the initial client for the stream, so no position to jump to.


Here is where the second client wants to view the existing stream

Code:

2014/01/08 07:40:00.311    Received client request: 192.168.1.179|OpenLiveStream|38110|0|125|DJCH/125
2014/01/08 07:40:00.321    OpenLiveStream Reply 01/04: smb://sean:*******@CRAY/Recorded TV2/TempXBMC/LiveTV_192.168.1.155_Digital Cable_125_2014_01_08_07_38_52.ts
2014/01/08 07:40:00.321    OpenLiveStream Reply 02/04: smb://sean:*******@CRAY/Recorded TV2/TempXBMC/LiveTV_192.168.1.155_Digital Cable_125_2014_01_08_07_38_52.ts
2014/01/08 07:40:00.321    OpenLiveStream Reply 03/04: 24870912
2014/01/08 07:40:00.321    OpenLiveStream Reply 04/04: <EOF>
2014/01/08 07:40:00.321    Finished request OpenLiveStream in 0.01s

Reply line 3 indicates to the 2nd client that it should skip ahead in the file to position 24870912 (this is the number of bytes, so approximately 24MB into the file).


So the server side all looks good. The problem is that on your client side logs I dont see any log output from the pvr plugin. I dont know if this is an openElec thing or what but normally in xbmc logs there is heaps of rerence to our addon but in yours, a search for "wmc" doesnt even find a single line. Perhaps need to try and set the logging differently (try turning on debug I guess) although normally you dont need debug level to see these things.

As your openElec build says it was built on November 26 last year, can you confirm you do infact have the most recent version of the pvr.wmc addon installed and that you updated it yourself? It needs to be 0.1.92 in order for this feature to work, which was only released around xmas time for linux x86

[Talguy]

I haven't had time to test this out yet. I'll try to this weekend

[goblygoop]

confirmed they were both 0.1.92. Odd thing is now it goes to the same position. Nothing has changed on my side (WTF). Though there is a 500ms to 3 sec delay in their position..beofre it was 5+ min. Only thing i did was turn on debugging so I could take logs for you guys to see and it starts working correctly.

[scarecrow420]

Glad that it works, but yes that is kind of weird it wasnt for a while there. Keep an eye on it and let us know if it happens again...

Also FYI a few seconds difference between clients is normal... basically the first client to watch the program will be a few seconds behind real time (infact, however long it took to get the stream started, remux it, and the client to start playing it). The 2nd client to join in is typically closer to real time, since there is less time taken on the backend as the file already exists, so it';s really only the time it takes the client to start playing the stream.