22:33 < [g2]> [mbm]: any clue when jafa will be back ?
22:34  * [g2] is wonding about creating a patch for hdhomerun_config that would accepet a signal to stop saving to a file
22:35 < [g2]> then another program could control it in a slightly cleaner fashion than just killing the process
22:36 < [mbm]> it was only intended to be a quick and dirty way to save a sample for debugging
22:37 < [mbm]> don't quite understand why you'd want to do anything more advanced with it
22:38 < [g2]> I've got a scheduling backend for my dual tuner pvr-500 card, I'd like to add hdhomerun support
22:38 < [g2]> I'm pulling the Schedules Direct data then I post process and have nearly the TIVO equivalent
22:39 < [g2]> series mgmt, etc...
22:39 < [mbm]> and I take it all of this is in the form of a script?
22:39 < [g2]> yeah for now
22:40 < [g2]> it could run on any platform there are some open and some closed perl scripts
22:40 < [mbm]> figured otherwise you'd be using libhdhomerun and manipulating the socket directly
22:40 < [g2]> right I looked at that a little and that's a possiblitiy
22:42 < [g2]> it just that happauge cards (pvr-500) are my first target
22:43 < [g2]> but plug-ins for different targets are very sensible and trivial
22:43 < [g2]> basically I just need the tune and save to a file from the device
22:43 < [mbm]> well, the save feature is nothing more than udp socket->file
22:43 < [mbm]> there's no reason to spawn hdhomerun_config to do it
22:43 < [g2]> tcp I think
22:44 < [mbm]> communication is tcp, mpeg data is udp
22:44 < [g2]> doh
22:45 < [g2]> can the mpeg data be tcp too ?
22:45 < [mbm]> not anymore
22:45 < [g2]> either that or there should be a patch for checking for missed packets
22:45 < [mbm]> there was an experimental build which supported it
22:46 < [g2]> udp is fine if there's a little error checking that can be done on the host side
22:46 < [mbm]> well, it's a transport stream
22:46 < [g2]> but that misses the point
22:46 < [g2]> the point being is easy to check a sequence number
22:46 < [mbm]> it will recover better from errors if you drop packets then it will if you force it through tcp and reorder packets
22:47 < [g2]> and hard to decode mpeg-2
22:47 < [mbm]> and yes, mpeg does have sequence numbers
22:47 < [mbm]> one of the status results from the hdhomerun tells you the count of sequence errors
22:48 < [g2]> right so I need to clear the counter before I start sending info
22:48 < [g2]> and then somehow check after the saving is done
22:48 < [mbm]> you have no control over the counter
22:48 < [g2]> that's kinda my point
22:48 < [mbm]> no, you're just not understanding what I'm trying to get across
22:49 < [g2]> you point that MPEG-2 already handles it ?
22:49 < [g2]> your
22:49 < [mbm]> suppose you have a recording with corruption
22:49 < [mbm]> the question is "where did the corruption come from?"
22:49 < [mbm]> it could have been encoded into the video (no sequence errors)
22:50 < [mbm]> it could have been a reception problem (sequence errors recorded on the hdhr)
22:50 < [g2]> fully agree, and I'm interested in isolating 3
22:51 < [g2]> so if the network issues are taken out of the equation, then only issues of 1 and 2 are there which are hdhomerun specific
22:52 < [g2]> I spent nearly 5 years producing smart networm managment that stop the finger pointing between ISPs and Telcos
22:53 < [g2]> I'm simply wanting to separate the issues with hdhr captuers
22:53 < [g2]> captures
22:53 < [g2]> smart network management equimpment
22:54 < [mbm]> and the debug info will tell you all of the above
22:55 < [g2]> are all the udp data packets ack'ed ?
22:55 < [g2]> from the host to the hdhr ?
22:56 < [g2]> 'cause if they are not, then the hdhr has know clue what's dropped on the net or at the receiving host
22:56 < [g2]> has no clue
22:56 < [g2]> versus has no way of knowing
22:57 < [mbm]> if you really want to be paranoid, implement a sequence counter on the host, look for sequence errors, compare the results with the sequence errors reported by the hdhomerun
22:57 < [mbm]> if they differ you have transmission problems