Not logged in. · Lost password · Register
Forum: Discussion RSS
Multiple connections to MythTV cause pauses and freezes
Avatar
kenapp #1
Member since Mar 2007 · 3 posts
Group memberships: Members
Show profile · Link to this post
Subject: Multiple connections to MythTV cause pauses and freezes
Hi,

First off, thanks. I have not been able to stream MythTV to a PC using either VideoLan or Windows Media Player. The MythTV Player is a wonderful solution to stream recordings from a Linux box to a Windows Box. I really like the fact that you can expand the columns in the recording window in the new version so that you can view the whole title of a recording.

I set up a Knoppmyth server in order to stream training programs over a LAN. Everything works great when 1 to 3 people access recordings simultaneously. But once that number goes 4 simultaneous users, the stream being fed to the MythTV Player experiences pauses, and occasionally the stream just freezes. When I test this situation, 5 people are accessing different recordings on the knoppmyth server.

I first used the default settings for the player (version 0.3.4). Then I upgraded to version 0.3.5. I changed the MythTV player settings so that it connects via a samba share rather than the myth protocol, and I disabled stream buffering as recommended in another thread.

I am streaming through the network at 100mps full duplex.

My question is this: Is the player, as well as MythTV made to support multiple simultaneous connections? If so, are there other tweaks to the player's settings that my help create more stable viewing performance when several people are simultaneously accessing video.

Is there any documentation, or could someone help explain how the following settings in the config.xml file affect performance of the player?
        <VideoPacketBuffer>75</VideoPacketBuffer>
        <AudioPacketBuffer>75</AudioPacketBuffer>
        <VideoframeBuffer>5</VideoframeBuffer>
        <StreamBufferSize>1048576</StreamBufferSize>
        <StreamBufferBlockSize>32768</StreamBufferBlockSize>
        <PreBufferingPercent>10</PreBufferingPercent>
        <ReBufferingPercent>50</ReBufferingPercent>

Thanks for any assistance you may be able to provide.

- Ken
Avatar
Kuroneko #2
Member since Jan 2007 · 40 posts · Location: Pittsburgh, PA, USA
Group memberships: Members
Show profile · Link to this post
Hrm, I use 3 machines (mostly at the same time) to watch stuff off the box, and the only time I constantly see pauses is when a recording deleted off the backend (not the recording thats playing, just any recording). However, it'll go back to normal is 5-10mins.
Mikkel (Administrator) #3
User title: Developer
Member since Oct 2006 · 222 posts · Location: Copenhagen, Denmark
Group memberships: Administrators, Members
Show profile · Link to this post
In reply to post #1
My question is this: Is the player, as well as MythTV made to support multiple simultaneous connections? If so, are there other tweaks to the player's settings that my help create more stable viewing performance when several people are simultaneously accessing video.
I do not think your problem is on the client side, but rather on your backend side. Both the backend and MythTv Player should be able to support many connections. When you stream normally from the backend, the player uses 4 connections to the backend. When you use a samba share, only 2 connections are used and none are used to transfer the recordings. The file is simply opened through the samba share and the backend does not even know we are accessing it. Also, your 100Mbit cable should not be the problem at all.

My guess is that your disk-system in the backend is not capable of providing 4 streams at the same time. As Kuroneko say, it might also be affected by other things, such as your are deleting or recording shows. I am far from an expert on this. Have you tried playing 4 streams from the real mythtv frontend to see if that works? (Even though I would be surprised if it did). Maybe you should write to the "real" mythtv-users list about this. People on that list know much more about the hardware and how many streams you can get out of a normal backend setup.
In your case, you actually want to enable the streambuffer and maybe even increase it to make the player more resistant to periods where no data is received. The streambuffer can only help you if your backend is able to provide 4 streams at the same time in average.  If that is not the case, then it will only push the problem a bit and you will still have pauses and rebufferings, once in a while.

You are right that the buffering (or anything else), is not well documented. Let me briefly sketch the buffer system. Btw. You can change many of the settings in the preference dialog. (Right-click and press preferences).
If you right-click and press 'status' you can see the current status of the buffers.

1. Data is first read into the streambuffer. This buffer is the buffer that other players does not have.(I think) The buffer is filled by a separate thread and it simply means that data is buffered before it is actually needed by the decoder library. It should make the player more resistant to temporary decrease in bandwidth, as is the case in wireless networks.
2. The recording is then demuxed into audiopackets and videopackets. The maximum number of packets which can be buffered is <VideoPacketBuffer>75</VideoPacketBuffer>, and <AudioPacketBuffer>75</AudioPacketBuffer>.
3. VideoFrames are then decoded into real images. <VideoframeBuffer>5</VideoframeBuffer> is the maximum number of decoded images which can be buffered.

PreBufferingPercent When a new recording is opened this is how much the buffers are filled before starting to play. This is also used when seeeking. The larger, the longer time it takes.
ReBufferingPercent When there is a buffer underrun, the player pauses and fills the buffers before resuming. The rebufferingPercent is the percentage of the buffers that is filled before the player starts again.


Please tell me if the explanation did not make sense.. and keep us posted on your progress ;)

cheers,

\Mikkel
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please note the verification code from the picture into the text field next to it.
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Page created in 238.8 ms (114.3 ms) · 44 database queries in 80.5 ms
Current time: 2012-02-06, 19:27:02 (UTC +01:00)