[mythtv-users] Lossless-cut Not Ubuntu

[Doug Vaughan]

Stile,
I do not doubtwhat you are saying but a couple of things surprise me and 
one of which may very well be the root of the problem.First a nothing 
that matterscomment, sofar I have only seen my own HDPVR 1080i 
recordings marked in MythTV as having FPS of 29.970. It does not matter 
as the value in the DB is used in a formula and assuming it is correct 
would give accurate cuts.

     More import is that I was definitely told that in v0.26 the 
recorded file name used local date time while the database contained UTC 
data times. There is code in Lossless Cut (import/mythtvinterface.py) 
called "_set_sql_starttime()" which, if it is dealing with mythtv 
version is v0.26, converts the recorded record start time to a UTC start 
timewhich is used in all direct SQL calls.

     Lossless Cut uses the MythTV python bindings as much as it can but 
sometimes needs to use SQL call. The MythTV python bindings convert all 
data times to local date times before returning them to the calling 
code. It is a feature of convenience so python scripts so not have to 
worry about the recent change to UTC date times.

     It so happens that the method "_get_fps_and_more()" which queries 
for the recordedmarkup record type "32" is using a SQL call and 
therefore requires a UTC start date time. If for some reason your 
database starttime values are not as expected by Lossless Cut then the 
query for the recordedmarkup type "32" will fail and Lossless Cut will 
abort with the message you are seeing.

Upgrading your install is still important but may not get things to 
work. I tested Lossless Cut successfully with v0.26 in a VirtualBox VM. 
Test data included my own recordings (v0.25) and those from users with 
v0.26 and they did not have issues.

With what you have told me I am getting a gut feel that this date time 
conversion for SQL calls is the problem. I have emailed you replacement 
code for "import/mythtvinterface.py" which willnot convert the data 
times. This can easily determine if the conversion is causing the 
issue.In the mean time I will talk with a developer to make sure that I 
heard correctly about the recorded filenamealways being in local time.

Is there a chance that theMythTV backend you are recording with is not 
set to local time? I am not sure if the Lossless Cut script would use a 
differentlocal time than what the MythTV BE is using but at this point I 
am ready to consider any possibility. The Lossless Cut code is using 
standard python dateutil functions and does not do anything funky with 
your machine locally date time settings.

Bare with me, we will get to the bottom of this issue.

Doug