Mailing List Archive: MythTV: Users

mythvidexport problems

Index | Next | Previous | View Threaded

mythtv at tapanitarvainen

Apr 5, 2012, 9:50 AM

Post #1 of 4 (202 views)
Permalink

mythvidexport problems

On Mar 27 21:39, Michael T. Dean (mtdean [at] thirdcontact) wrote:

> there's little reason with current MythTV not to
> put recordings (TV and/or movies) into Video Library.

That encouraged me to experiment with mythvidexport.py.
While it kind of works, I encountered a number of problems
(in order of importance to me):

* It apparently cannot handle recordings with non-ASCII
characters in their title at all ("ERROR: ascii").
Being in Finland, that's like half of all my recordings.

* Commercial detection data is lost (despite --skiplist option) -
everything becomes "Not flagged" (and there seems to be no
way of detecting commercials in Video Library).

* It occasionally loses metadata for no obvious reason,
with status "ERROR:DBData() could not read from database".

* Screenshot is lost in the process, which makes browsing
less convenient.

* It is cumbersome to use: You have to start the job,
wait for it to complete, check the recording is OK
in the Video library, then delete it from recordings.
(Presumably this could be automated, IF it were
reliable enough.)

Whether these are actual bugs or if I've done something
wrong, I'm not sure. Suggestions would be welcome.

- In case it matters, I'm running 0.24+fixes (Ubuntu 11.10 packages).

--
Tapani Tarvainen
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

raymond at wagnerrp

Apr 5, 2012, 10:34 AM

Post #2 of 4 (193 views)
Permalink

Re: mythvidexport problems [In reply to]

On 4/5/2012 12:50, Tapani Tarvainen wrote:
> On Mar 27 21:39, Michael T. Dean (mtdean [at] thirdcontact) wrote:
>
>> there's little reason with current MythTV not to
>> put recordings (TV and/or movies) into Video Library.
> * It apparently cannot handle recordings with non-ASCII
> characters in their title at all ("ERROR: ascii").
> Being in Finland, that's like half of all my recordings.

Python 2.x and Unicode have a long running animosity towards each
other. Ascii is handled independently from unicode and other encoded
text, however there are tons of methods that require ascii strings and
cannot operate using non-ascii text. My use of Unicode tends to be
limited to the occasional stylized character in a name, so I tend to
make changes that silently break Unicode operation and never notice.

> * Commercial detection data is lost (despite --skiplist option) -
> everything becomes "Not flagged" (and there seems to be no
> way of detecting commercials in Video Library).

The script merely passes the data into the bindings. Chances are the
bindings are storing those values against the wrong `filename` in the
database.

> * Screenshot is lost in the process, which makes browsing
> less convenient.

Assuming the metadata lookup is performed properly, it is supposed to
pull a new screenshot, as well as other artwork, from the matching entry
on TheTVDB.com. The fallthrough behavior for when this data is not
available needs to be improved.

> * It is cumbersome to use: You have to start the job,
> wait for it to complete, check the recording is OK
> in the Video library, then delete it from recordings.
> (Presumably this could be automated, IF it were
> reliable enough.)

This version adds three options, --delete, --safe, and --really-safe.
--safe checks the destination filesize against the source to make sure
some data wasn't lost somewhere in the transfer, and causes the user job
to fail if they don't match. --really-safe performs an SHA1 hash of both
source and destination instead. --delete will delete the source file,
enforcing the use of --safe if neither are manually defined on the
command line. I've not yet pushed it to the wiki as it uses methods in
the bindings only available in 0.25.

https://github.com/wagnerrp/mythtv-scripts/blob/master/python/mythvidexport.py

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtv at tapanitarvainen

Apr 5, 2012, 12:03 PM

Post #3 of 4 (193 views)
Permalink

Re: mythvidexport problems [In reply to]

On Thu, Apr 05, 2012 at 01:34:01PM -0400, Raymond Wagner (raymond [at] wagnerrp) wrote:

> >* Screenshot is lost in the process, which makes browsing
> > less convenient.
>
> Assuming the metadata lookup is performed properly, it is supposed
> to pull a new screenshot, as well as other artwork, from the
> matching entry on TheTVDB.com.

There practically never are matching entries there for Finnish programs
(and even for American ones only when the name hasn't been translated).

> The fallthrough behavior for when this data is not available needs
> to be improved.

That would be nice. The description &c are usually copied just
fine, only the screenshot is lost, so perhaps it wouldn't be
too hard to fix.

> This version adds three options, --delete, --safe, and
> --really-safe. --safe checks the destination filesize against the
> source to make sure some data wasn't lost somewhere in the transfer,
> and causes the user job to fail if they don't match. --really-safe
> performs an SHA1 hash of both source and destination instead.

Does either check metadata?
(As noted, I occasionally lose just metadata even though
the actual recording is fine.)

--
Tapani Tarvainen
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

raymond at wagnerrp

Apr 5, 2012, 12:14 PM

Post #4 of 4 (188 views)
Permalink

Re: mythvidexport problems [In reply to]

On 4/5/2012 15:03, Tapani Tarvainen wrote:
> On Thu, Apr 05, 2012 at 01:34:01PM -0400, Raymond Wagner (raymond [at] wagnerrp) wrote:
>
>>> * Screenshot is lost in the process, which makes browsing
>>> less convenient.
>> Assuming the metadata lookup is performed properly, it is supposed
>> to pull a new screenshot, as well as other artwork, from the
>> matching entry on TheTVDB.com.
> There practically never are matching entries there for Finnish programs
> (and even for American ones only when the name hasn't been translated).

To which I would say, make an account and add those entries! :)
The content on that site is all user-generated. Someone has to do it.

>> The fallthrough behavior for when this data is not available needs
>> to be improved.
> That would be nice. The description&c are usually copied just
> fine, only the screenshot is lost, so perhaps it wouldn't be
> too hard to fix.

There's a bit more to do than just that. Right now, if a lookup fails,
it uses the 'generic' format. The built in default for that format
would work fine for movies, but when used against a television series,
you would just have one episode overwriting the next, and completely not
the behavior you are looking for.

>> This version adds three options, --delete, --safe, and
>> --really-safe. --safe checks the destination filesize against the
>> source to make sure some data wasn't lost somewhere in the transfer,
>> and causes the user job to fail if they don't match. --really-safe
>> performs an SHA1 hash of both source and destination instead.
> Does either check metadata?
> (As noted, I occasionally lose just metadata even though
> the actual recording is fine.)

Nope. It just makes sure the file copied over accurately. The DBData
error you mentioned previously may be the result of the 'generic'
behavior I mentioned above, and an unhandled exception when you try to
overwrite one video with another.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads