Mailing List Archive

The usage of the 'recordedfile' table?
Facts:
The 'recordedfile' table stores details about the
containerformat and the used codecs of a recording,
as well as the file properties of that recording.

The 'recordedfile' table gets updated during in
progress-recording or after a recording is finished.
Mythtranscode updates the content of a recordedfile as well.
The entry of the 'recordedfile' is deleted on deletion of the recording.
Upnp reads codec and other data from the 'recordedfile' table.

Parts of the content of the 'recordedfile' is available
in the 'recordedmarkup' table as well:
Aspect, dimensions, duration, average frames speed of a recording.

The program "mythcommflag --rebuild" updates the markup table entries
listed above, but does not update the 'recordedfile' table entry.

In contrast, the frontend displays details about a recording which
are taken from the entry of the 'recordedprogram' table:
See file mythtv\programs\mythfrontend\progdetails.cpp
For example, the icons for the videodimensions (HD, 1080, 720)
are derived from the 'recordedprogram' entry,
i.e.: from the 'videoprop' and 'audioprop' values.


Please consider the following use case:
An existing recording is transcoded in place by a user job,
which changed the filename, codecs, duration, dimensions
etc. of that recording.
The user job has to take care that the 'recordedfile' table
and the 'recordedmarkup' table are updated accordingly.


Now my questions:
By what means do you update the 'recordedfile' table?
I know of the Python Bindings (v31+) or running an SQL command
directly, but are there other means to achieve this, like the
ServicesAPI or "mythutil" ?

In case of transcoding to a suitable video container format,
like matroska or mp4, do I need to preserve the entries in the
'recordedmarkup' table at all?
Can I simply clear the recorded-seek and -markup table entries
for that recording in that case?

Roland
Re: The usage of the 'recordedfile' table? [ In reply to ]
On 7/23/20 6:37 AM, Roland Ernst wrote:
> Facts:
> The 'recordedfile' table stores details about the
> containerformat and the used codecs of a recording,
> as well as the file properties of that recording.
>
> The 'recordedfile' table gets updated during in
> progress-recording or after a recording is finished.
> Mythtranscode updates the content of a recordedfile as well.
> The entry of the 'recordedfile' is deleted on deletion of the recording.
> Upnp reads codec and other data from the 'recordedfile' table.
>
> Parts of the content of the 'recordedfile' is available
> in the 'recordedmarkup' table as well:
> Aspect, dimensions, duration, average frames speed of a recording.
>
> The program "mythcommflag --rebuild" updates the markup table entries
> listed above, but does not update the 'recordedfile' table entry.
>
> In contrast, the frontend displays details about a recording which
> are taken from the entry of the 'recordedprogram' table:
> See file mythtv\programs\mythfrontend\progdetails.cpp
> For example, the icons for the videodimensions (HD, 1080, 720)
> are derived from the 'recordedprogram' entry,
> i.e.: from the 'videoprop' and 'audioprop' values.
>
>
> Please consider the following use case:
> An existing recording is transcoded in place by a user job,
> which changed the filename, codecs, duration, dimensions
> etc. of that recording.
> The user job has to take care that the 'recordedfile' table
> and the 'recordedmarkup' table are updated accordingly.
>
>
> Now my questions:
> By what means do you update the 'recordedfile' table?
> I know of the Python Bindings (v31+) or running an SQL command
> directly, but are there other means to achieve this, like the
> ServicesAPI or "mythutil" ?
>
> In case of transcoding to a suitable video container format,
> like matroska or mp4, do I need to preserve the entries in the
> 'recordedmarkup' table at all?
> Can I simply clear the recorded-seek and -markup table entries
> for that recording in that case?
>
> Roland
>
Hi Roland

I have been transcoding with handbrake for a long time. I use a script
which updates recorded and recordedfile. I also run "mythutil
--clearseektable" because seektables do not work with mkv files and
confuse the playback. The script is here
https://github.com/bennettpeter/mythscripts/blob/master/install/opt/mythtv/bin/tcimport.sh
. This works fine but is not the best solution since I have to change it
from time to time when there are schema changes.

Regarding the recordedfile table, I don't know how necessary it is or
how accurate it is.

I should really have used an api or mythutil for all the updates and not
have accessed the database directly. But this was done long ago.

Peter
Re: The usage of the 'recordedfile' table? [ In reply to ]
On 23/07/2020 14:28, Peter Bennett wrote:
>
> On 7/23/20 6:37 AM, Roland Ernst wrote:
>> Facts:
>> The 'recordedfile' table stores details about the
>> containerformat and the used codecs of a recording,
>> as well as the file properties of that recording.
>>
>> The 'recordedfile' table gets updated during in
>> progress-recording or after a recording is finished.
>> Mythtranscode updates the content of a recordedfile as well.
>> The entry of the 'recordedfile' is deleted on deletion of the recording.
>> Upnp reads codec and other data from the 'recordedfile' table.
>>
>> Parts of the content of the 'recordedfile' is available
>> in the 'recordedmarkup' table as well:
>> Aspect, dimensions, duration, average frames speed of a recording.
>>
>> The program "mythcommflag --rebuild" updates the markup table entries
>> listed above, but does not update the 'recordedfile' table entry.
>>
>> In contrast, the frontend displays details about a recording which
>> are taken from the entry of the 'recordedprogram' table:
>> See file mythtv\programs\mythfrontend\progdetails.cpp
>> For example, the icons for the videodimensions (HD, 1080, 720)
>> are derived from the 'recordedprogram' entry,
>> i.e.: from the 'videoprop' and 'audioprop' values.
>>
>>
>> Please consider the following use case:
>> An existing recording is transcoded in place by a user job,
>> which changed the filename, codecs, duration, dimensions
>> etc. of that recording.
>> The user job has to take care that the 'recordedfile' table
>> and the 'recordedmarkup' table are updated accordingly.
>>
>>
>> Now my questions:
>> By what means do you update the 'recordedfile' table?
>> I know of the Python Bindings (v31+) or running an SQL command
>> directly, but are there other means to achieve this, like the
>> ServicesAPI or "mythutil" ?
>>
>> In case of transcoding to a suitable video container format,
>> like matroska or mp4, do I need to preserve the entries in the
>> 'recordedmarkup' table at all?
>> Can I simply clear the recorded-seek and -markup table entries
>> for that recording in that case?
>>
>> Roland
>>
> Hi Roland
>
> I have been transcoding with handbrake for a long time. I use a script
> which updates recorded and recordedfile. I also run "mythutil
> --clearseektable" because seektables do not work with mkv files and
> confuse the playback. The script is here
> https://github.com/bennettpeter/mythscripts/blob/master/install/opt/mythtv/bin/tcimport.sh
> . This works fine but is not the best solution since I have to change it
> from time to time when there are schema changes.
>
> Regarding the recordedfile table, I don't know how necessary it is or
> how accurate it is.

I have used my mythDVBcut script for years. It includes

{{{

# tell mythDB about new filename and set the 'transcoded' flag
echo "update recorded set basename='${OUTFILE}', transcoded = 1
where recordedid = '$recordedid' ; " |
mysql -N -u${DBUserName} -p${DBPassword} -h${DBLocalHostName} ${DBName}

# Update the container type, needed for uPnP playback. Empty will
work too, if the transcoded flag is set.
# This is a HACK pending 0.28 release, when mythutil should do it.
See Ticket #12388

echo "update recordedfile set basename = '${OUTFILE}', container =
'MPEG2-PS' where recordedid = '$recordedid' ;" |
mysql -N -u${DBUserName} -p${DBPassword} -h${DBLocalHostName} ${DBName}

}}}

John P
>
> I should really have used an api or mythutil for all the updates and not
> have accessed the database directly. But this was done long ago.
>
> Peter
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org