Granted, I am using a development build (compiled from latest CVS source), but I've noticed some odd behavior during playback from a ReplayTV device. Basically, I select a show for playback and I get either a black screen or a mostly black screen with a greenish banner along the bottom and random garbage along the top. If I bring up the display, I see the counter counting up and the progress bar incrementing, but no video. I then try to playback a show from my DVArchive server and everything is fine.
I did notice that the ReplayTV in question here was currently recording when I tried the playback. Does this somehow affect the performance?
I just tested with last nights build and didn't encounter a problem. What you describe sounds like how it will behave if the mpeg stream is not feed to the decoder fast enough when starting a new stream.
i.e It doesn't jerk and breakup it just goes blank.
What was the resolution of the recording?
I'm guessing high. Have never seen the problem with
standard or medium resolution.
I'll record a couple shows in high resolution & see if I can reproduce.
Is you network wired 100BT using an etherswitch (not a hub)?
Does it happen all the time for all shows, etc ?
Network: Wired 100BT with switch (Belkin WAP with 4port switch)
Just for more background, this does not happen all the time, just sometimes (although it seems to be more and more frequent these days). The unit is also a 5040 upgraded to a 5200.
I recorded a couple high res shows and have
not been able to reproduce.
Does it happen if you reboot the mvp and don't use
any functionality other than replaytv?
eg: the mplayer stuff, etc...
I rebooted the MVP and went directly into the ReplayTV menu option. I pulled up one of the offending recording off my "Bedroom" unit (problem seems localized on this unit), and tried to play it. Same thing.
Here is some more background info. I have two ReplayTVs on the network ("Family Room" and "Bedroom") as well as a DVArchive server. Playback is most seemless from the DVArchive server. Playback from the "Family Room" unit is OK, but sometimes there is a bit of a lag when starting a show, skipping forward, or skipping back. Playback is worst of all on the "Bedroom" unit.
You know, as I am typing this, I just realized an interesting pattern. Playback seems to get better the farther away you get on the network from the MVP. The "Bedroom" unit is in the armoir next to the MVP (and plugged into the same switch/WAP). The DVArchive box is the farthest away in terms of length of wire (and there are are 3 switches between it and the MVP!).
Just more data. I don't know if this means anything.
OK. Most likely the rtv in question is a little slow
pushing data to the mvp. (Or recent mvp changes
hava reduced the mvp demuxer performance) Either way,
we'll try adding an option to increase the mpg chunk
size RTV streams with from 96 to 128K.
There's a good chance that will fix the problem.
I'll try to get you something this weekend.
Try the following development build.
# Name: dongle.bin.mvpmc-20051021
# Bytes: 2106912
# Date: October 21 2005 19:10:02 PDT
It allows specifying an option to increase the mpg
chunk size handed to the demuxer in 32k increments.
The default is 3 (96Kbytes)
Try starting mvpmc using the following options:
mvpmc -R "ip=discover chunksz=4"
This will use 128K chunks.
If that doesn't work you can try chunksz 5 or 6.
Please let me know the results.
I just built a new dongle file from the latest source in CVS (10/22/05). Here are the results of my experimentation thus far:
chunksz=4 --> Video started playing fine, but froze after about 15 seconds
chunksz=5 --> Video played back normally, but using skip forward or skip back caused video to freeze
chunksz=6 --> Video played back normally, and skip forward and skip back work (although there is a bit of a lag before video resumes)
Anyway, it seems that this solution is working.
Thats good it works.
All I can guess is something is really slow on that one RTV box about responding.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.