network-clients dont work (freezes) (1 Viewer)

[lar282]

12855

I tried 12855(server and client) and it freezes for me to.
Does work to back 15 sec.


//Lasse

 

[josu]

Hey,
Is this just a problem with remote network clients? I seem to be geting these problems with the my network client and with the client installed at the same pc as the server.

I don't see the difference between a local and remote client, don't both work in exactly the same way? just the remote maybe a bit slower(in theroy) since its over the ethernet.

I've not a attached any logs since I'm sure they are the same as everyone elses. Client hangs, going back in time after channel changes fixes the problem.

I'm running the MP SVN 12847 and TVEngine/TVPlugin 12855. Accoring to the SVN change log something rtsp has been fixed but I'm not sure if that fix is included in the revs that I got. Does the time on the SVN change log relate to the time on the SVN binary snapshots?

Hello,

I have tested something more with ethereal and vlc on the server (with local client) :

1. mp on the server has direct access to the ts-buffer-files without rtsp ( there is no network-traffic)

2. If you test with vlc, you can only get access over the IP / DNS to the stream, and here is the same effect how on the network-clients.
If you open with vlc the right ts-buffer-file with vlc (file-open-.....), vlc has no problems and you can look live-tv equal mp, without freezing.

That means, the problem is by rtsp !!!!
The setup of mp on the server can see, that there is the tv-server installed and so, mp get direct-access to the ts-files!!!


What I dont understand is the orange progressbar in fullscreen-mode on the clients. There is no green or red stripe !!! MP on the server has no stripes, no green/red and no orange !!!
On the server, you cannot play backward or forward, too !!??


Some strange behavior are on clients, too:

If you change the channels, and you play backward, you have all changed channels in one ts-buffer-stream. It looks like you switch the channels, but if you play this one ts-file with vlc, you can see, that all channels are contained in one file !!!

P.S: some channels can meanwhile changed without freezing, but only less channels. I dont know, why some channels run ??????

 

[Robertxc]

I still can repro on 12855.

Steps used to reproduce:

- Started MP.
- Entered MyTv.
- Pressed TVOn Button.
- Channel data (program info) updated, no Image (black) tv preview.
- Entered fullscreen. Waited aroun 10 secs.
- Changed channel. Still no image.
- Skipped 15secs back. Now theres image playing.
- Exited MP.

Frodo, another feedback about long running streams: Yesterday I left my system running almost 5 hours after a -15secs skip. Stream did not freeze after the skip.

I did exactly the same, and left it running overnight with no problems. The next morning when I tried to change channel, MP imediately crashed. I'm running MP client and server over gigabit LAN.

 

[joboehl]

Robertx,

When you mean crashed after the long period, you mean that neither a 15sec skip bring the image back. Not even trying to go to menu right?

 

[Robertxc]

The channel was on BBC News 24. I clicked "Guide" on my MCE remote, and then selected "BBC1 Scotland", at which point MP imediately crashed and exited. I then got the "Media Portal has encountered and error and needs to close..." dialogue box.

 

[DooMMasteR]

I got the same hanging problem...HW is far capable enough, but it does not work...I'll now try the jump back procedure

???is the timeshift stored on the client???

 

[joboehl]

???is the timeshift stored on the client???

no

 

[josu]

I got the same hanging problem...HW is far capable enough, but it does not work...I'll now try the jump back procedure

???is the timeshift stored on the client???

hello DooMMasteR,

no, the timeshift-files are stored on the tv-server

It seems a little better since the latest svn (12866), but the mainproblem exists further

 

[joboehl]

Apparently this is not happening in every scenario. Frodo for example can't reproduce. Maybe we should try to identify what we might have in common could help identify possible causes?

I've made some modifications to MP so I could add some extra debugging and try to understand what is happening.

I don't quite get the complete flow of the information inside MP until it get's displayed in the screen. But I noticed the folowing:

- After a channel change, Planescene.presentimage stops being called, and as such framecount is not updated. Framecount in 0 makes code goes down to a path where the "repaint - 0" that most people report as being the last thing before image freezes being called.

- After skipping 15secs back, after a couple of iterations, PresentImage get's called again. As soon as this happens, image starts displaying again.

Now, I don't get where and how PresentImage is called so I can't tell if it's ok for it not being called or not. But this observations might help devs to narrow down a little bit more on what's going on.

The log of this findings can be found in pastebin: http://pastebin.team-mediaportal.com/12002

Hope it helps.

 

[Frodo]

- After a channel change, Planescene.presentimage stops being called, and as such framecount is not updated. Framecount in 0 makes code goes down to a path where the "repaint - 0" that most people report as being the last thing before image freezes being called.

Thats normal
Normally what happens is:
1. rtsp filter receives raw data from the server
2. mpeg-2 demultiplexer demultiplexes the stream into seperate audio/video streams
3. audio/video codecs decode the audio/video stream
4. codecs deliver (uncompressed) video/audio frames to the video renderer / audio renderer
5. audio/video renderer present the frame to the user

Now when in step #3 the video (mpeg-2) decoder does not decode anything anymore then it will not deliver uncompressed video frames to the video renderer (VMR9)
MP detects this and will start 'repainting' the last video frame received in step #4 by the VMR9 until the decoder starts to deliver new frames again

So this is the result and not the cause of the freeze problems
The problem is why the process stops in step #1 - #3

It could be
- step #1) rtsp filter does not receive any data anymore (could be checked with network sniffing)
- step #3) video codec does not receive any packets anymore from the demultiplexer
- step #3) video codec does receive packets from the demultiplexer, but with the wrong timestamp
E.g. the video codec expects a packet with timestamp 100.00 but it receives an packet with timestamp 55.00 . In this case the codec drops the packets until it receives packet with timestamp 100.00 and then continues decoding and delivering video frames again

Even worse:
The video codec expects a packet with timestamp 100.00 but it receives an packet with timestamp 200.00 . In this case the codec waits until the current time is 200.00 and then continues decoding and delivering video frames again

Now about the seeking, if you seek fwd/bkwd the entire directshow graph is 'reset' in terms of timing. All filters flush their (internal) buffers and start all over again.. This probably explains why this causes video to re-appear again...

Frodo