[mythtv-users] Lossless-cut Not Ubuntu
Doug Vaughan
r.d.vaughan at rogers.com
Sat Nov 3 12:21:13 UTC 2012
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
More information about the mythtv-users
mailing list