Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#7793 closed defect (fixed)

writeStringList: Error, No data written on writeBlock

Reported by: Falk Stern <falk@…> Owned by: Isaac Richards
Priority: major Milestone: 0.23
Component: MythTV - General Version: 0.22-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Hi,

when I try to watch recordings from a frontend on my MacBook?, mythfrontend just hangs as soon as I select "Watch Recordings" from the menu.

My backend runs on Ubuntu 9.10.

Last message from backend is: "MythSocket?(8ea6de8:48): writeStringList: Error, No data written on writeBlock (810 errors)"

Backend: [falk@oban:~]% mythbackend --version Please include all output in bug reports. MythTV Version : 22994 MythTV Branch : branches/release-0-22-fixes Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.5.2 Options compiled in:

linux profile using_oss using_alsa using_pulse using_jack using_backend using_dvb using_firewire using_frontend using_glx_proc_addr_arb using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

Frontend: [falk@rincewind:Contents/MacOS]% ./MythFrontend? --version Please include all output in bug reports. MythTV Version : 22957 MythTV Branch : branches/release-0-22-fixes Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.4.3 Options compiled in:

release darwin_da using_corevideo using_backend using_darwin using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_lirc using_mheg using_opengl_video using_qtwebkit using_appleremote using_bindings_perl using_bindings_python using_darwin_da using_opengl using_ffmpeg_threads using_live using_mheg

Traces with "-v socket,network,extra" have been attached as bzip2.

Attachments (3)

mythfrontend.log.bz2 (3.0 KB) - added by Falk Stern <falk@…> 14 years ago.
Frontend Log
mythbackend.log.bz2 (126.8 KB) - added by Falk Stern <falk@…> 14 years ago.
Backend Log
mythtv-writestringlist-timeout.patch (365 bytes) - added by Colin Cross <mythtv@…> 14 years ago.

Download all attachments as: .zip

Change History (11)

Changed 14 years ago by Falk Stern <falk@…>

Attachment: mythfrontend.log.bz2 added

Frontend Log

Changed 14 years ago by Falk Stern <falk@…>

Attachment: mythbackend.log.bz2 added

Backend Log

comment:1 Changed 14 years ago by Colin Cross <mythtv@…>

I have the same problem when using wireless 802.11g between my backend and frontend, but not when I use ethernet. The problem seems to be the 1 second timeout in writestringlist - QUERY_RECORDINGS on my backend returns 2.6MB of data, which takes 1.5s to transfer over the wireless network.

I'll attach a patch that resets the 1 second timeout after each successful call to writeBlock, so it will only fail if there is a continuous 1 second period with no network activity. That way a large transfer over a slow network will not fail, but if the connection actually stops, it will still fail in 1 second.

Changed 14 years ago by Colin Cross <mythtv@…>

comment:2 Changed 14 years ago by Stuart Auchterlonie

Milestone: unknown0.23

comment:3 Changed 14 years ago by Falk Stern <falk@…>

Would it be possible to merge this into -fixes?

comment:4 Changed 14 years ago by Falk Stern <falk@…>

Hi all,

I just rebuild libmythdb with the above mentioned patch and it works.

Thanks for the quick fix!

comment:5 Changed 14 years ago by jaham@…

I can also confirm that the attached patch fixes timeout problems with my MediaMvp? frontend.

comment:6 Changed 14 years ago by Stuart Auchterlonie

Resolution: fixed
Status: newclosed

(In [23372]) Closes #7793. Restart the no data written timer every time we successfully write some data.

comment:7 Changed 14 years ago by Stuart Auchterlonie

(In [23484]) Refs #7793. Don't restart the timer every time we receive data. Rather, just keep a count of data received and once the timer has half expired, restart it if some data has been received in this period. Should be a bit more efficient.

comment:8 Changed 14 years ago by analogue@…

I'm seeing the same problem using MythBox? as a client. I'm curious as to why there is even a timer attached to the transfer of data. I would think this sort of mechanism imposes some sort of quality of service requirements on the connection between the FE and BE. Why even bother when this seems more a responsiblity of the network stack (TCP/IP) rather than the application domain.

From a mythtv client perspective, it seems prohibitive to just abandon the socket and not complete writing out the remaining data.

BTW, I how do I get a login for trac? Poking around the trac site doesn't seem to have any obvious instructions on how to register.

Note: See TracTickets for help on using tickets.