[mythtv-users] mythcommflag not updating database

Fri Oct 24 01:36:00 UTC 2014

> On 24 Oct 2014, at 8:33 am, "John Pilkington" <J.Pilk at tesco.net> wrote:
> 
>> On 23/10/14 22:08, Mark Perkins wrote:
>> 
>> 
>>>> On 20 Oct 2014, at 6:08 pm, "John Pilkington" <J.Pilk at tesco.net> wrote:
>>>> 
>>>> On 20/10/14 03:44, Justin Alcorn wrote:
>>>> It's from an HDPVR - H.264 recordings - so I can't use mythtranscode.
>>>> Instead I'm using ffmpeg to cut and then put it back together.
>>>> 
>>>> I also convert it to .mp4 because mythroku won't see .mpg file.
>>>> 
>>>> DOes mythcommflag just not rebuild seektables for .mp4 files?  THe
>>>> .mpg files that have seektables are H.264, just in an MPEG container.
>>>> --
>>>> Justin B. Alcorn
>>>> PGP Fingerprint A36D D691 C5B0 BE15 5A2A AF49 AA1C 372C
>>>> 
>>>> 
>>>>> On Sat, Oct 18, 2014 at 5:04 PM, Mark Perkins <perkins1724 at hotmail.com> wrote:
>>>>> 
>>>>> 
>>>>>> On 19 Oct 2014, at 4:18 am, "Justin Alcorn" <justin at jalcorn.net> wrote:
>>>>>> 
>>>>>> When I cut commercials out of a recording, and run mythcommflag
>>>>>> --rebuild, it reports running successfully but never updates the
>>>>>> recordedseektable. When I run with --verbose database, I see it
>>>>>> accessing the database, updating the recordedmarkup table, so I know
>>>>>> it has access to the database
>>>>>> 
>>>>>> Oct 18 12:36:02 gossamer mythcommflag: mythcommflag[7727]: I
>>>>>> CoreContext mythdbcon.cpp:193 (OpenDatabase) [DBManager0] Connected to
>>>>>> database 'mythconverg' at host: localhost
>>>>>> Oct 18 12:36:02 gossamer mythcommflag: mythcommflag[7727]: D
>>>>>> CoreContext mythcontext.cpp:432 (FindDatabase) FindDatabase() -
>>>>>> Success!
>>>>>> ...
>>>>>> Oct 18 12:36:02 gossamer mythcommflag: mythcommflag[7727]: I
>>>>>> CoreContext mythdbcon.cpp:193 (OpenDatabase) [DBManager1] Connected to
>>>>>> database 'mythconverg' at host: localhost
>>>>>> Oct 18 12:36:02 gossamer mythcommflag: mythcommflag[7727]: I
>>>>>> CoreContext mythdbcon.cpp:709 (exec) MSqlQuery::exec(DBManager1)
>>>>>> SELECT data FROM settings WHERE value = 'language' AND hostname =
>>>>>> 'gossamer' <<<< Took 0ms, Returned 1 row(s)
>>>>>> Oct 18 12:36:02 gossamer mythcommflag: mythcommflag[7727]: D
>>>>>> CoreContext mythdbcon.cpp:779 (seekDebug) MSqlQuery::next(DBManager1)
>>>>>> Result: "data = EN_US"
>>>>>> ...
>>>>>> Oct 18 12:37:09 gossamer mythcommflag: mythcommflag[7727]: I
>>>>>> CoreContext mythdbcon.cpp:709 (exec) MSqlQuery::exec(DBManager1)
>>>>>> INSERT INTO recordedmarkup (chanid, starttime, mark, type, data)
>>>>>> VALUES ( '2267', '2014-10-07T06:30:00Z', 0, '34', '684292'); <<<< Took
>>>>>> 0ms
>>>>>> 
>>>>>> But no inserts or updates at all into recordedseek. I do see it
>>>>>> looking for existing information:
>>>>>> 
>>>>>> Oct 18 12:39:25 gossamer mythcommflag: mythcommflag[7860]: I
>>>>>> CoreContext mythdbcon.cpp:709 (exec) MSqlQuery::exec(DBManager1)
>>>>>> SELECT mark, offset FROM recordedseek WHERE chanid = '2267' AND
>>>>>> starttime = '2014-10-07T06:30:00Z' AND type = '7' ; <<<< Took 0ms,
>>>>>> Returned 0 row(s)
>>>>>> 
>>>>>> If I go ahead and tell mythcommflag to flag commercials, I still get
>>>>>> no seektable, and can't fast forward or rewind correctly.
>>>>>> 
>>>>>> I do see this error, but it seems that people say it's not consequential.
>>>>>> 
>>>>>> 2014-10-18 12:39:25.209938 C mythcommflag version: master
>>>>>> [v0.28-pre-2291-gd97aeef] www.mythtv.org
>>>>>> 2014-10-18 12:39:25.209969 C Qt version: compile: 4.8.6, runtime: 4.8.6
>>>>>> 2014-10-18 13:27:41.525877 E decoding error
>>>>>> eno: Unknown error 541478725 (541478725)
>>>>>> 
>>>>>> What am I missing? I thought this was how you built that table.
>>>>>> --
>>>>>> Justin B. Alcorn
>>>>>> PGP Fingerprint A36D D691 C5B0 BE15 5A2A AF49 AA1C 372C
>>>>>> _______________________________________________
>>>>> 
>>>>> How are you removing the commercials? Are you transcoding at the same time and if so to what format?
>>> 
>>> This looks rather like
>>> 
>>> https://code.mythtv.org/trac/ticket/12010#comment:6
>>> 
>>> with the seek table being rebuilt, but not properly.  I've only seen DVB-T2, though.
>>> 
>>> _______________________________________________
>> 
>> I'm not convinced, but maybe. Personally I suspect that mythcommflag --rebuild does not work with mp4 container - but was hoping some-one like Jean-Yves would give a definitive answer.
>> 
>> I know when I was doing a series of experiments some time ago that I could not get any seek table at all with a mp4 container (h264 codec). But it would a mpg container (h264 codec).
>> 
>> IIRC I did try John's patch once but it didn't make any difference and I had moved on by then so only put minimal effort into it. From memory John you were getting a seek table just with limited values? But that you also use mpg container and h264?
> Yes, I believe it's h264 in an mpeg container.  I haven't tried unpatched in master, but in 0.27-fixes the rebuilt seektable often had 'keyframes' separated by tens of seconds; with the patch almost all of the original kfs are found, around a second apart.
> 
> I haven't looked into this, but I thought mp4 didn't need them, and ISTR JYA indicating that he thinks a good player shouldn't need them for many formats.

Yes, my experience (sample size = 1) was that MythTV didn't need the seek table for playback or seeking mp4, only for making commskiplist and cutlist which if commercials have already been removed are not needed.

> 
> My quick-and-dirty h264-cutter cuts at kfs found by the editor. Reasonably ok on a first pass but hopeless without the patch on a re-run; and skipping etc was bad, at least on my hardware.
> 
>> Justin try a transcode to mpg container and see what results you get?
> 
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org