[mythtv] RE: New version of windows filters (was: Mythweb andWindows Media Player over Samba)

Torbjörn Jansson torbjorn.jansson at mbox200.swipnet.se
Tue May 18 05:17:13 EDT 2004



> 
>> That doesn't look right.
>> Coud you run mythbackend with "-v all" and send the log from when it
>> fails? I don't understand why it fails, it shoudn't.
> 
> Here is the relevant part of my mythbackend log using -v all:
> 2004-05-17 21:55:35 WriteBlock(): Aborting WriteBlock, write
> to socket failed!
> 2004-05-17 21:55:35 2       -1
> 
> Note that I have 338 recordings, with the MASH episode shown being
> the oldest and not the recording I was attempting to play.
> 
> I installed the 0.6.2 filters on my desktop and was able to connect
> to the backend and watch the recording.  Here's the logfile:
> 

It's strange that it works on one computer and not the other.
Is it posibel that you have different types of networks on those two
computers? I think I remember you said something about wirless lan or maybe
that was someone else.
Or is there different versions of windows on those two computers?

I think I have an idea on whats going on and I think I can reproduce the
problem, actualy I think when I increased the request size from 65536 to
128000 I got the same problem.

Maybe someone that know a bit more about the mythtv network protocol can
answer this question:
During filtransfer does mythbackend expect data to be read from the data
socket during a REQUEST_BLOCK command?
When request block returns with a response all data shod have been read
right?

So if someone (me) desides to first send a REQUEST_BLOCK and then wait for
it to complete before reading from the socket bad thing will happen, unless
the default buffer windows uses for the socket happends to be larger than
the request size.

That woud explain why it worked on some computers and not others.

> 2004-05-17 22:46:46 5       65536  (repeated over and over as
> the file played)
> 

That woud be the read requests from the player, and that's how it shoud look
like during playback.

> However, the sound was slightly off and would become several
> seconds delayed after seeking.  I use a PVR-250 to record,
> then transcode to MPEG-4, and I had not edited the recording.
> I watched an MPEG-2 recording that hadn't finished transcoding
> and the sound was in sync both before and after seeking, however
> the player did crash on me a couple of times when seeking.
> 
> Any idea why one computer would get the writeblock error and not
> the other?  Is the audio snyc issue a known problem with transcoded
> recordings? 
> 

The file you had a/v sync problems was a mpeg4/rtjpeg (nupplevideo type)
file right?
It may be caused by how I fixed the transcodeing support, when I did it I
realized I may have caused some a/v sync problems if the audio timestamps is
not in sync with the video timestamps at the new position.

I didn't think it was a big problem since I never experienced any a/v sync
issues, but I guess I'll have to take a look at it again.
I usualy don't transcode any files so maybe that's why I didn't have any
problems.



More information about the mythtv-dev mailing list