Mailing List Archive

On Tue, 10 May 2022 07:55:00 +0000, you wrote:

>Hi,
>
>Since I upgraded to mythtv V32 as a result of upgrading to Ubuntu 22.04, I have discovered that the recordid field is not being set in the recorded table. This is a problem for me because I use mythpodcaster to create podcasts of some recorded radio shows that I can then transfer to my iPhone and listen to when I'm out and about.
>
>Can anyone think of a reason why this is happening (is it by design) or, better yet, how I can fix it without manually updating the records for the affected recordings?

I just checked my database (Ubuntu 20.04, MythTV v32-fixes) and I have
no recordings with recordid null. I thought recordid was required,
but the column does allow null values.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

-----Original message-----
From: John Pilkington <johnpilk222@gmail.com>
Sent: Tuesday 10th May 2022 9:55
To: Dave Pearson (Lists) <lists@the-pearsons.co.uk>
Subject: Re: [mythtv-users] recordid not being set in recorded table in Myth v32


On 10/05/2022 08:55, Dave Pearson (Lists) wrote:
> Hi,
>
>
> Since I upgraded to mythtv V32 as a result of upgrading to Ubuntu 22.04,
> I have discovered that the recordid field is not being set in the
> recorded table. This is a problem for me because I use mythpodcaster to
> create podcasts of some recorded radio shows that I can then transfer to
> my iPhone and listen to when I'm out and about.
>
>
> Can anyone think of a reason why this is happening (is it by design) or,
> better yet, how I can fix it without manually updating the records for
> the affected recordings?
>
>
> Regards,
>
> Dave.

I haven't used recordid, but the wiki says that it 'references
record(recordedid)'

I do use recordedid, which is now available after two 'info' keystrokes
from the 'Show Recordings' screen. I use a modified theme that shows it
by default.

https://github.com/MythTV/mythtv/issues/464

John P



Hi John,



Thanks for your Input, but recordedid is a different value to recordid:



mysql> select title, starttime, recordid, recordedid from recorded where recordid = 0 order by starttime asc;

+---------------------------+---------------------+----------+------------+

| title                     | starttime           | recordid | recordedid |

+---------------------------+---------------------+----------+------------+

| Top Gear                  | 2022-05-09 07:00:00 |        0 |      31108 |

| This Week's Magic Singles | 2022-05-09 19:55:33 |        0 |      31110 |

| Non-Stop Magic Hits       | 2022-05-10 05:03:20 |        0 |      31114 |

| Non-Stop Magic Hits       | 2022-05-10 05:52:58 |        0 |      31116 |

+---------------------------+---------------------+----------+------------+

4 rows in set (0.00 sec)







In my case, any new recordings seem to have a value of 0 for recordid, the value for recordedid is OK. At the moment I'm updating the field manually, so that my Mythodcaster process will work, but that's not ideal.



Regards,

Dave.

-----Original message-----
From: Stephen Worthington <stephen_agent@jsw.gen.nz>
Sent: Tuesday 10th May 2022 10:56
To: Discussion about MythTV <mythtv-users@mythtv.org>
Subject: Re: [mythtv-users] recordid not being set in recorded table in Myth v32


On Tue, 10 May 2022 07:55:00 +0000, you wrote:

>Hi,
>
>Since I upgraded to mythtv V32 as a result of upgrading to Ubuntu 22.04, I have discovered that the recordid field is not being set in the recorded table. This is a problem for me because I use mythpodcaster to create podcasts of some recorded radio shows that I can then transfer to my iPhone and listen to when I'm out and about.
>
>Can anyone think of a reason why this is happening (is it by design) or, better yet, how I can fix it without manually updating the records for the affected recordings?

I just checked my database (Ubuntu 20.04, MythTV v32-fixes) and I have
no recordings with recordid null. I thought recordid was required,
but the column does allow null values.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org



Hi Stephen,



It doesn't appear to set the value to null, it appears to set it to 0



Regards,

Dave.

On Tue, 10 May 2022 10:09:36 +0000, you wrote:

>-----Original message-----
>From: Stephen Worthington?<stephen_agent@jsw.gen.nz>
>Sent: Tuesday 10th May 2022 10:56
>To: Discussion about MythTV <mythtv-users@mythtv.org>
>Subject: Re: [mythtv-users] recordid not being set in recorded table in Myth v32
>
>
>On Tue, 10 May 2022 07:55:00 +0000, you wrote:
>
>>Hi,
>>
>>Since I upgraded to mythtv V32 as a result of upgrading to Ubuntu 22.04, I have discovered that the recordid field is not being set in the recorded table. This is a problem for me because I use mythpodcaster to create podcasts of some recorded radio shows that I can then transfer to my iPhone and listen to when I'm out and about.
>>
>>Can anyone think of a reason why this is happening (is it by design) or, better yet, how I can fix it without manually updating the records for the affected recordings?
>
>I just checked my database (Ubuntu 20.04, MythTV v32-fixes) and I have
>no recordings with recordid null. I thought recordid was required,
>but the column does allow null values.

>
>Hi Stephen,
>
>It doesn't appear to set the value to null, it appears to set it to 0

That is quite different. I have one recording with recordid=0, and it
is very old but not actually my oldest recording. It has no matching
recording rule. My recordid=4 is for NCIS and matches a number of
recordings.

Do you have a recording rule with recordid=0? That is perfectly
valid, as far as I know.

sudo su
mysql mythconverg
select * from record where recordid=0\G
quit
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, 10 May 2022 10:08:24 +0000, you wrote:


>Hi John,
>
>
>
>Thanks for your Input, but recordedid is a different value to recordid:
>
>
>
>mysql> select title, starttime, recordid, recordedid from recorded where recordid = 0 order by starttime asc;
>
>+---------------------------+---------------------+----------+------------+
>
>| title ? ? ? ? ? ? ? ? ? ? | starttime ? ? ? ? ? | recordid | recordedid |
>
>+---------------------------+---------------------+----------+------------+
>
>| Top Gear? ? ? ? ? ? ? ? ? | 2022-05-09 07:00:00 |? ? ? ? 0 |? ? ? 31108 |
>
>| This Week's Magic Singles | 2022-05-09 19:55:33 |? ? ? ? 0 |? ? ? 31110 |
>
>| Non-Stop Magic Hits ? ? ? | 2022-05-10 05:03:20 |? ? ? ? 0 |? ? ? 31114 |
>
>| Non-Stop Magic Hits ? ? ? | 2022-05-10 05:52:58 |? ? ? ? 0 |? ? ? 31116 |
>
>+---------------------------+---------------------+----------+------------+
>
>4 rows in set (0.00 sec)
>
>
>
>
>
>
>
>In my case, any new recordings seem to have a value of 0 for recordid, the value for recordedid is OK. At the moment I'm updating the field manually, so that my Mythodcaster process will work, but that's not ideal.
>
>
>
>Regards,
>
>Dave.

The recordedid column is the index for the recorded table. It is
autoincremented for each new recording. The recordid column is the
index for the record table (the recording rules). It is
autoincremented for the creation of each new recording rule. Each row
in the recorded table should have the recordid column set to the
recordid of the recording rule in the record table that created that
recording.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Resending to list

On 10/05/2022 11:08, Dave Pearson (Lists) wrote:
>
>
> -----Original message-----
> *From:* John Pilkington <johnpilk222@gmail.com>
> *Sent:* Tuesday 10th May 2022 9:55
> *To:* Dave Pearson (Lists) <lists@the-pearsons.co.uk>
> *Subject:* Re: [mythtv-users] recordid not being set in recorded
> table in Myth v32
>
> On 10/05/2022 08:55, Dave Pearson (Lists) wrote:
> > Hi,
> >
> >
> > Since I upgraded to mythtv V32 as a result of upgrading to Ubuntu 22.04,
> > I have discovered that the recordid field is not being set in the
> > recorded table. This is a problem for me because I use mythpodcaster to
> > create podcasts of some recorded radio shows that I can then transfer to
> > my iPhone and listen to when I'm out and about.
> >
> >
> > Can anyone think of a reason why this is happening (is it by design) or,
> > better yet, how I can fix it without manually updating the records for
> > the affected recordings?
> >
> >
> > Regards,
> >
> > Dave.
>
> I haven't used recordid, but the wiki says that it 'references
> record(recordedid)'
>
> I do use recordedid, which is now available after two 'info' keystrokes
> from the 'Show Recordings' screen. I use a modified theme that shows it
> by default.
>
> https://github.com/MythTV/mythtv/issues/464
>
> John P
>
>
> Hi John,
>
>
> Thanks for your Input, but recordedid is a different value to recordid:
>
> mysql> select title, starttime, recordid, recordedid from recorded where
> recordid = 0 order by starttime asc;
>
> +---------------------------+---------------------+----------+------------+
>
> | title                     | starttime           | recordid | recordedid |
>
> +---------------------------+---------------------+----------+------------+
>
> | Top Gear                  | 2022-05-09 07:00:00 |        0 |      31108 |
>
> | This Week's Magic Singles | 2022-05-09 19:55:33 |        0 |      31110 |
>
> | Non-Stop Magic Hits       | 2022-05-10 05:03:20 |        0 |      31114 |
>
> | Non-Stop Magic Hits       | 2022-05-10 05:52:58 |        0 |      31116 |
>
> +---------------------------+---------------------+----------+------------+
>
> 4 rows in set (0.00 sec)
>
>
>
> In my case, any new recordings seem to have a value of 0 for recordid,
> the value for recordedid is OK. At the moment I'm updating the field
> manually, so that my Mythodcaster process will work, but that's not ideal.
>
>
> Regards,
> .
> Dave.
>
OK, here's mine in master. el7 box, Server version: 5.5.68-MariaDB
MariaDB Server !!

Mostly I record single items via the EPG. Radio recordings have been
postprocessed to 'mp3' and deleted.

{{{

MariaDB [mythconverg]> select title, starttime, recordid, recordedid
from recorded where recordedid > 37228 order by starttime asc;
+----------------------------------------+---------------------+----------+------------+
| title | starttime |
recordid | recordedid |
+----------------------------------------+---------------------+----------+------------+
| First Britons | 2022-04-22 13:13:00 | 34273 |
37236 |
| Attenborough and the Mammoth Graveyard | 2022-05-02 18:58:00 | 34334 |
37300 |
| Lighthouses | 2022-05-06 19:58:00 | 34351 |
37324 |
| Spring | 2022-05-07 08:28:00 | 34352 |
37326 |
+----------------------------------------+---------------------+----------+------------+

}}}

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

On 10/05/2022 12:58, John Pilkington wrote:

>>
> OK, here's mine in master.  el7 box, Server version: 5.5.68-MariaDB
> MariaDB Server  !!

I just tried it on the fedora 34 box, MariaDB 10.5.15. The results were
similar to those below, with both recordid and recordedid having
numerical values increasing with date.
>
> Mostly I record single items via the EPG.  Radio recordings have been
> postprocessed to 'mp3' and deleted.
>
> {{{
>
> MariaDB [mythconverg]> select title, starttime, recordid, recordedid
> from recorded where recordedid > 37228 order by starttime asc;
> +----------------------------------------+---------------------+----------+------------+
>
> | title                                  | starttime           |
> recordid | recordedid |
> +----------------------------------------+---------------------+----------+------------+
>
> | First Britons                          | 2022-04-22 13:13:00 | 34273 |
>      37236 |
> | Attenborough and the Mammoth Graveyard | 2022-05-02 18:58:00 | 34334 |
>      37300 |
> | Lighthouses                            | 2022-05-06 19:58:00 | 34351 |
>      37324 |
> | Spring                                 | 2022-05-07 08:28:00 | 34352 |
>      37326 |
> +----------------------------------------+---------------------+----------+------------+
>
>
> }}}
>
> John

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

On 5/10/22 08:24, John Pilkington wrote:
> On 10/05/2022 12:58, John Pilkington wrote:
>
>>>
>> OK, here's mine in master.  el7 box, Server version: 5.5.68-MariaDB
>> MariaDB Server  !!
>
> I just tried it on the fedora 34 box, MariaDB 10.5.15.  The results
> were similar to those below, with both recordid and recordedid having
> numerical values increasing with date.
>>
>> Mostly I record single items via the EPG.  Radio recordings have been
>> postprocessed to 'mp3' and deleted.
>>
>> {{{
>>
>> MariaDB [mythconverg]> select title, starttime, recordid, recordedid
>> from recorded where recordedid > 37228 order by starttime asc;
>> +----------------------------------------+---------------------+----------+------------+
>>
>> | title                                  | starttime           |
>> recordid | recordedid |
>> +----------------------------------------+---------------------+----------+------------+
>>
>> | First Britons                          | 2022-04-22 13:13:00 |
>> 34273 |       37236 |
>> | Attenborough and the Mammoth Graveyard | 2022-05-02 18:58:00 |
>> 34334 |       37300 |
>> | Lighthouses                            | 2022-05-06 19:58:00 |
>> 34351 |       37324 |
>> | Spring                                 | 2022-05-07 08:28:00 |
>> 34352 |       37326 |
>> +----------------------------------------+---------------------+----------+------------+
>>
>>
>> }}}
>>
>> John
>
>
The recordid is required to associate the recording with a recording
rule. If it is zero that will affect the setting of metadata on the
recording and use of the frontend to update the recording rule from the
recording.

There may be a few unusual cases where it is not set (e.g. recordings
from Live TV) but it should be set in all normal cases.

There does not seem to be any change in the latest master. recordid is
still being set on tests I have done.

Peter

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

-----Original message-----
From: Peter Bennett <pb.mythtv@gmail.com>
Sent: Tuesday 10th May 2022 15:15
To: mythtv-users@mythtv.org
Subject: Re: [mythtv-users] recordid not being set in recorded table in Myth v32



On 5/10/22 08:24, John Pilkington wrote:
> On 10/05/2022 12:58, John Pilkington wrote:
>
>>>
>> OK, here's mine in master. el7 box, Server version: 5.5.68-MariaDB
>> MariaDB Server !!
>
> I just tried it on the fedora 34 box, MariaDB 10.5.15. The results
> were similar to those below, with both recordid and recordedid having
> numerical values increasing with date.
>>
>> Mostly I record single items via the EPG. Radio recordings have been
>> postprocessed to 'mp3' and deleted.
>>
>> {{{
>>
>> MariaDB [mythconverg]> select title, starttime, recordid, recordedid
>> from recorded where recordedid > 37228 order by starttime asc;
>> +----------------------------------------+---------------------+----------+------------+
>>
>> | title | starttime |
>> recordid | recordedid |
>> +----------------------------------------+---------------------+----------+------------+
>>
>> | First Britons | 2022-04-22 13:13:00 |
>> 34273 | 37236 |
>> | Attenborough and the Mammoth Graveyard | 2022-05-02 18:58:00 |
>> 34334 | 37300 |
>> | Lighthouses | 2022-05-06 19:58:00 |
>> 34351 | 37324 |
>> | Spring | 2022-05-07 08:28:00 |
>> 34352 | 37326 |
>> +----------------------------------------+---------------------+----------+------------+
>>
>>
>> }}}
>>
>> John
>
>
The recordid is required to associate the recording with a recording
rule. If it is zero that will affect the setting of metadata on the
recording and use of the frontend to update the recording rule from the
recording.

There may be a few unusual cases where it is not set (e.g. recordings
from Live TV) but it should be set in all normal cases.

There does not seem to be any change in the latest master. recordid is
still being set on tests I have done.

Peter

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



Thanks Peter,



I don't have any rules that set recordid to 0, as you say it is normally related to a rule, and each scheduled recording has it's own recordid, so my rule to record "Blues Power" on Planet Rock has it's own recordid and this is used by Mythpodcaster to determine if the program should be transcoded or not. 



I think I need to try setting up a new recording rule to see if it gets set for that - it it does, I;ll just delete the existing rules for my MythPodcaster stuff and it should sort itself out - I'll let this list know if that solves it?



Regards,

Dave.

-----Original message-----
From: Peter Bennett <pb.mythtv@gmail.com>
Sent: Tuesday 10th May 2022 15:15
To: mythtv-users@mythtv.org
Subject: Re: [mythtv-users] recordid not being set in recorded table in Myth v32



On 5/10/22 08:24, John Pilkington wrote:
> On 10/05/2022 12:58, John Pilkington wrote:
>
>>>
>> OK, here's mine in master. el7 box, Server version: 5.5.68-MariaDB
>> MariaDB Server !!
>
> I just tried it on the fedora 34 box, MariaDB 10.5.15. The results
> were similar to those below, with both recordid and recordedid having
> numerical values increasing with date.
>>
>> Mostly I record single items via the EPG. Radio recordings have been
>> postprocessed to 'mp3' and deleted.
>>
>> {{{
>>
>> MariaDB [mythconverg]> select title, starttime, recordid, recordedid
>> from recorded where recordedid > 37228 order by starttime asc;
>> +----------------------------------------+---------------------+----------+------------+
>>
>> | title | starttime |
>> recordid | recordedid |
>> +----------------------------------------+---------------------+----------+------------+
>>
>> | First Britons | 2022-04-22 13:13:00 |
>> 34273 | 37236 |
>> | Attenborough and the Mammoth Graveyard | 2022-05-02 18:58:00 |
>> 34334 | 37300 |
>> | Lighthouses | 2022-05-06 19:58:00 |
>> 34351 | 37324 |
>> | Spring | 2022-05-07 08:28:00 |
>> 34352 | 37326 |
>> +----------------------------------------+---------------------+----------+------------+
>>
>>
>> }}}
>>
>> John
>
>
The recordid is required to associate the recording with a recording
rule. If it is zero that will affect the setting of metadata on the
recording and use of the frontend to update the recording rule from the
recording.

There may be a few unusual cases where it is not set (e.g. recordings
from Live TV) but it should be set in all normal cases.

There does not seem to be any change in the latest master. recordid is
still being set on tests I have done.

Peter

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



Hi Peter,



Yes, setting up a new recording rule resulted in a recordid being set, so I should be able to fix my problem by deleting the existing rules and re-creating them



Thanks to everyone, John Pilkington, Stephen Worthington etc. for your input - as usual great support from this mailing list.



Regards,

Dave.