[mythtv-users] Schedules Direct DataDirect replacement service testing

Robert Eden rmeden at gmail.com
Tue Oct 7 06:04:45 UTC 2014


On 10/7/2014 12:11 AM, Gary Buhrmaster wrote:
> On Tue, Oct 7, 2014 at 4:49 AM, Robert Eden <rmeden at gmail.com> wrote:
> ....
>> Most reports show TMS-DD takes twice as long as SD-DD.  Were you seeing
>> timeouts from TMS-DD and just never noticed it?
> No, I was occasionally seeing failures (and noticed).
>
> However it seems that the TMS-DD trickled the
> data over an extended period (the total time was
> more than the SD-DD service time) so the MythTV
> mythdownloadmanager 60 second abort timeout was
> not usually the cause (as long as mythdownloadmanager
> is getting data, it resets the abort timer for each "chunk").
> I am presuming that the new SD-DD service collects
> all the data before passing it back so the 60
> second mythdownloadmanager abort timeout
> applies.  So, this is indirect regression caused by
> (that I am presuming) the particular way you are
> providing the service.
>
> Does that explanation make sense (I am not asking
> if you have a solution, just does my observation
> make sense)?
Yup, I think you hit the nail on the head.  I am storing all the data and then outputting it at once.  My reason is to report a status in the 
header... I can't know the status until I get all the data!

Robert



More information about the mythtv-users mailing list