[mythtv-users] mythcommflag not updating database

Justin Alcorn justin at jalcorn.net
Fri Oct 24 03:11:53 UTC 2014


Mythfrontend player can't skip on a H.264 in a MP4 container.  And I
have older recordings , transcoded without loss into an MP4 container
(For Mythroku) that have seektable entries.  So I'm not sure what
changed.
--
Justin B. Alcorn
PGP Fingerprint A36D D691 C5B0 BE15 5A2A AF49 AA1C 372C


On Thu, Oct 23, 2014 at 9:36 PM, Mark Perkins <perkins1724 at hotmail.com> wrote:
>
>
>> 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
> _______________________________________________
> 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


More information about the mythtv-users mailing list