Mailing List Archive

On Sun, 5 Sep 2021 00:39:17 +0100, you wrote:

>Here is something that used to work and no longer works.
>
>Because Channel 4 HD does not have EIT data on Freesat, I used to copy the
>EIT from Channel 4 with this line
>
>/home/tv/bin/cross-eit.py -o /tmp/export.xml 19211,"hd.channel4.com"
>
>and then add it to the schedule with this other line
>
>/usr/bin/mythfilldatabase --refresh-all --verbose xmltv --file --sourceid 1
>--xmlfile /tmp/export.xml
>
>...all this after having visited
>
>http://localhost/mythweb/settings/tv/channels
>
>and ensured that the line for Channel 4 HD had an xmltvid of hd.channel4.com
>and a useonairguide value of OFF.
>
>However, while the cross-eit.py command produces a plausible export.xml
>file, the mythfilldatabase command complains that it can't recognise
>hd.channel4.com as an xmltv channel identifier, although I confirm that
>that is the entry in the xmltvid column for the Channel 4 HD row in the
>localhost/mythweb interface.
>
>This used to work. Why does it no longer work and what can I do to fix it?
>
>Thank you

What version of cross-eit.py are you using? What version of MythTV?
The only version of cross-eit.py I can find is a Python 2 version,
which will not work with current MythTV versions which are Python 3
only.
_______________________________________________
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 Sun, 5 Sept 2021 at 04:33, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> What version of cross-eit.py are you using? What version of MythTV?
> The only version of cross-eit.py I can find is a Python 2 version,
> which will not work with current MythTV versions which are Python 3
> only.
>


I am on MythTV Version : v32.0~master.202108251032.a2cdb9047a~ubuntu20.04.1

cross-eit did indeed stop working with the move to python 3 but I fixed it
in April 2020 and posted the working version here in this thread.
There used to be an archive at gossamer-threads.com but it seems to have
disappeared, or I would point you at the message. I can repost if useful.
Anyway the point is that I had already solved that issue, cross-eit is
running and is indeed producing a plausible xml file, and the part that
isn't working is importing that file with mythfilldatabase, with the error
I mentioned.

On 05/09/2021 01:39, UB40D via mythtv-users wrote:
> This used to work. Why does it no longer work and what can I do to fix it?

What does the following database query yield?

select chanid,channum,sourceid,callsign,name from channel where
xmltvid='hd.channel4.com';

Does it indeed return at least a row having the value 1 in the sourceid
column?
_______________________________________________
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 Sun, 5 Sept 2021 at 08:08, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 05/09/2021 01:39, UB40D via mythtv-users wrote:
> > This used to work. Why does it no longer work and what can I do to fix
> it?
>
> What does the following database query yield?
>
> select chanid,channum,sourceid,callsign,name from channel where
> xmltvid='hd.channel4.com';
>
> Does it indeed return at least a row having the value 1 in the sourceid
> column?
>

Good question! And the answer is yes:

mysql> select chanid,channum,sourceid,callsign,name from channel where
xmltvid='hd.channel4.com';
+--------+---------+----------+--------------+--------------+
| chanid | channum | sourceid | callsign | name |
+--------+---------+----------+--------------+--------------+
| 22200 | 21200 | 1 | Channel 4 HD | Channel 4 HD |
+--------+---------+----------+--------------+--------------+
1 row in set (0.00 sec)
You had me worried there for a moment, thinking that mythweb and the
database might be out of sync. But apparently not.

> xmltvid='hd.channel4.com';
> +--------+---------+----------+--------------+--------------+
> | chanid | channum | sourceid | callsign | name |
> +--------+---------+----------+--------------+--------------+
> | 22200 | 21200 | 1 | Channel 4 HD | Channel 4 HD |
> +--------+---------+----------+--------------+--------------+
>
>
BTW is there any significance to the fact that chanid and channum are not
the same? Should they be? What's the difference between the two?

On Sun, 5 Sep 2021 07:45:57 +0100, you wrote:

>On Sun, 5 Sept 2021 at 04:33, Stephen Worthington <stephen_agent@jsw.gen.nz>
>wrote:
>
>> What version of cross-eit.py are you using? What version of MythTV?
>> The only version of cross-eit.py I can find is a Python 2 version,
>> which will not work with current MythTV versions which are Python 3
>> only.
>>
>
>
>I am on MythTV Version : v32.0~master.202108251032.a2cdb9047a~ubuntu20.04.1
>
>cross-eit did indeed stop working with the move to python 3 but I fixed it
>in April 2020 and posted the working version here in this thread.
>There used to be an archive at gossamer-threads.com but it seems to have
>disappeared, or I would point you at the message. I can repost if useful.
>Anyway the point is that I had already solved that issue, cross-eit is
>running and is indeed producing a plausible xml file, and the part that
>isn't working is importing that file with mythfilldatabase, with the error
>I mentioned.

The list archive site is now here:

https://lists.archive.carbon60.com/mythtv/

but it does not seem to have your Python 3 version of cross-eit.py,
and Google does not find it either. So please repost it, and I will
have a go running it and see if I can see anything.

The mythfilldatabase output you posted is quite explicit in the error
it is finding: "Unknown xmltv channel identifier: Channel - Skipping
channel." Is that still the error you are getting? If so, the
xmltvid in the .xml file you are importing is not matching anything in
the database. What is the output of:

head /tmp/export.xml

Is there only one channel showing in the headers at the top of the
file? If you cut and paste the xmltvid from there into this query, is
that xmltvid found in the database?

select sourceid,chanid,channum,name,callsign,xmltvid from channel
where xmltvid='<paste here>';

If found, does the sourceid for the channel match the sourceid you are
using in the mythfilldatabase command?
_______________________________________________
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 05/09/2021 08:54, UB40D via mythtv-users wrote:
>
>
> mysql> select chanid,channum,sourceid,callsign,name from channel
> where xmltvid='hd.channel4.com <http://hd.channel4.com>';
> +--------+---------+----------+--------------+--------------+
> | chanid | channum | sourceid | callsign     | name       |
> +--------+---------+----------+--------------+--------------+
> |  22200 | 21200   |        1 | Channel 4 HD | Channel 4 HD |
> +--------+---------+----------+--------------+--------------+
>
>
> BTW is there any significance to the fact that chanid and channum are
> not the same? Should they be? What's the difference between the two?
>
> _______________________________________________
> 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

I too converted cross-eit to use Python 3 and it is currently working
fine for me.

I have to edit the file when the clocks change as the line

date = dateobj + datetime.timedelta(seconds=time.altzone)

doesn't cope with the time change, do you have a fix?

As to your problem .

The 'chanid' value changes after every scan so i use something like.

select serviceid,chanid,channum,sourceid,callsign from channel where
callsign like("%Channel 4 HD%") ;

to get the correct value, however you have a valid xml file so that
should not be the issue.

I use the same mythfilldatabase command

/usr/bin/mythfilldatabase --refresh-all --verbose xmltv --file
--sourceid 1 --xmlfile /tmp/export.xml

So presuming sourceid is correct it should work.

What has changed recently on your system?

Have you recently scanned?

On Sun, 5 Sept 2021 at 09:21, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

>
> The list archive site is now here:
>
> https://lists.archive.carbon60.com/mythtv/
>
> but it does not seem to have your Python 3 version of cross-eit.py,
> and Google does not find it either. So please repost it, and I will
> have a go running it and see if I can see anything.
>

Thanks. I reposted it now (with headers from the original message, showing
that the new list archive is missing at least that post and probably
others).

The mythfilldatabase output you posted is quite explicit in the error
> it is finding: "Unknown xmltv channel identifier: Channel - Skipping
> channel." Is that still the error you are getting?


Yes: that's as far as I got in my debugging---narrowing it down to that, so
I posted just the relevant line after figuring it out. But I could not
discover why.


> If so, the
> xmltvid in the .xml file you are importing is not matching anything in
> the database. What is the output of:
>
> head /tmp/export.xml
>

It appears that the data is all in one line so it's monstruously long, but
the first few screen lines go like this:

$ head /tmp/export.xml

<?xml version="1.0" ?>

<!DOCTYPE tv SYSTEM "xmltv.dtd">

<tv><programme channel="hd.channel4.com" start="20210821015000"
stop="20210821022000"><title>Come Dine with
Me</title><sub-title>Yeovil</sub-title><desc>PR manager Emmy hopes to
impress her guests with locally sourced Somerset produce. But she has a
disaster with her hollandaise sauce.
(Ep1/5)</desc><category>Entertainment</category></programme><programme
channel="hd.channel4.com" start="20210821022000"
stop="20210821024500"><title>Come Dine with
Me</title><sub-title>Yeovil</sub-title><desc>Radio DJ Steve serves up a
cross between comfort food and fine dining. But he feels the pressure, and
an unwanted ingredient ends up on one guest's plate.
(Ep2/5)</desc><category>Entertainment</category></programme><program

I can see the "hd.channel4.com" in there, which I assume has been generated
by the command line parameter I supplied to cross-eit.

I copied from stuff I did years ago, based on advice from kind people on
the list, and which worked then. I am not sure where this particular
identifier came from in the first place. When I looked at the table of all
channels in mythweb, this channel seemed to be the only one with an xmltvid.


> Is there only one channel showing in the headers at the top of the
> file?


yes


> If you cut and paste the xmltvid from there into this query, is
> that xmltvid found in the database?
>

yes


>
> select sourceid,chanid,channum,name,callsign,xmltvid from channel
> where xmltvid='<paste here>';
>


-> where xmltvid='hd.channel4.com';

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

| sourceid | chanid | channum | name | callsign | xmltvid
|

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

| 1 | 22200 | 21200 | Channel 4 HD | Channel 4 HD |
hd.channel4.com |

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

1 row in set (0.00 sec)






>
> If found, does the sourceid for the channel match the sourceid you are
> using in the mythfilldatabase command?
>

yes: the command used was

/usr/bin/mythfilldatabase --refresh-all --verbose xmltv --file --sourceid 1
--xmlfile /tmp/export.xml

On Sun, 5 Sept 2021 at 09:23, John <jksjdevelop@gmail.com> wrote:

> I too converted cross-eit to use Python 3 and it is currently working fine
> for me.
>
> I have to edit the file when the clocks change as the line
>
> date = dateobj + datetime.timedelta(seconds=time.altzone)
>
> doesn't cope with the time change, do you have a fix?
>

I remember having to do the same change manually, probably following your
advice here on the list.

I have not fixed it so that it would do the change by itself. If I get it
to work again, I probably should. (Writing an if statement with last Sunday
in March / last Sunday in October---seems dumb but ought to work.)


> As to your problem .
>
> The 'chanid' value changes after every scan so i use something like.
>
> select serviceid,chanid,channum,sourceid,callsign from channel where
> callsign like("%Channel 4 HD%") ;
>
> to get the correct value, however you have a valid xml file so that should
> not be the issue.
>

In any case, your query gives the following on my system right now:

callsign like("%Channel 4 HD%") ;

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

| serviceid | chanid | channum | sourceid | callsign |

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

| 21200 | 22200 | 21200 | 1 | Channel 4 HD |

| 21200 | 31200 | 21200 | 1 | Channel 4 HD |

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

2 rows in set (0.01 sec)

I am not sure why I get two. Maybe a relic of multiple scans? No clue which
is the "correct" one (if either is).


> I use the same mythfilldatabase command
>
> /usr/bin/mythfilldatabase --refresh-all --verbose xmltv --file --sourceid
> 1 --xmlfile /tmp/export.xml
>
> So presuming sourceid is correct it should work.
>
> What has changed recently on your system?
>
> Have you recently scanned?
>
For some definition of recently, yes (a few months ago).

I hate rescanning because it always messes up so much stuff. I did it
because I thought I was missing some channels that might have moved around.

Certainly the Channel 4 HD was no longer working after that; but I forget
if it was still working just before.

On Sun, 5 Sept 2021 at 10:06, UB40D <ub40dd@googlemail.com> wrote:

>
>
> On Sun, 5 Sept 2021 at 09:21, Stephen Worthington <
> stephen_agent@jsw.gen.nz> wrote:
>
>>
>> The list archive site is now here:
>>
>> https://lists.archive.carbon60.com/mythtv/
>>
>> but it does not seem to have your Python 3 version of cross-eit.py,
>> and Google does not find it either. So please repost it, and I will
>> have a go running it and see if I can see anything.
>>
>
> Thanks. I reposted it now (with headers from the original message, showing
> that the new list archive is missing at least that post and probably
> others).
>

Actually it bounced: held for moderation because of message length.
So, meanwhile, here is a pastebin of just the script.

https://pastebin.com/d51VUASq

On Sun, 5 Sep 2021 08:54:25 +0100, you wrote:

>mysql> select chanid,channum,sourceid,callsign,name from channel where
>> xmltvid='hd.channel4.com';
>> +--------+---------+----------+--------------+--------------+
>> | chanid | channum | sourceid | callsign | name |
>> +--------+---------+----------+--------------+--------------+
>> | 22200 | 21200 | 1 | Channel 4 HD | Channel 4 HD |
>> +--------+---------+----------+--------------+--------------+
>>
>>
>BTW is there any significance to the fact that chanid and channum are not
>the same? Should they be? What's the difference between the two?

Chanid is an internal database index number generated automatically by
the channel scanning process. It is required to be unique. Channum
is the channel number used by the user to change to a channel in live
TV or the guide. There can be multiple channels with different chanid
values that have the same channum. For example, you may get the same
channel in HD from a DVB-T2 source, in SD from DVB-T and also from a
satellite or cable service. To distinguish between the different
channels with the same channum, the highest priority one will be used
first. You can set priority in quite complex ways, but usually you
will have higher priority for the HD versions of channels, either by
setting the channel table priority entry or by giving the DVB-T2
source higher priority.
_______________________________________________
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 Sun, 5 Sep 2021 10:14:11 +0100
UB40D via mythtv-users <mythtv-users@mythtv.org> wrote:

> On Sun, 5 Sept 2021 at 09:23, John <jksjdevelop@gmail.com> wrote:
>
>
> In any case, your query gives the following on my system right now:
>
> mysql> select serviceid,chanid,channum,sourceid,callsign from channel
> mysql> where
> callsign like("%Channel 4 HD%") ;
>
> +-----------+--------+---------+----------+--------------+
>
> | serviceid | chanid | channum | sourceid | callsign |
>
> +-----------+--------+---------+----------+--------------+
>
> | 21200 | 22200 | 21200 | 1 | Channel 4 HD |
>
> | 21200 | 31200 | 21200 | 1 | Channel 4 HD |
>
> +-----------+--------+---------+----------+--------------+
>
> 2 rows in set (0.01 sec)
>
> I am not sure why I get two. Maybe a relic of multiple scans? No clue
> which is the "correct" one (if either is).
>
>

Maybe one of them has the deleted field set and is the one with
an xmltvid value. Try running the query

select serviceid,chanid,channum,sourceid,callsign,deleted,xmltvid from
channel where callsign like("%Channel 4 HD%") ;

Steve
--
____________________________________________________________________
Steve Evans E-mail: mailto:stevee@gorbag.com
Registered Linux user #217906: http://counter.li.org
Public Encryption Key: http://www.gorbag.com/public-key.html
____________________________________________________________________

5.10.61-gentoo Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz GNU/Linux

10:24:26 up 4 days, 23:00, 5 users, load average: 0.29, 0.10, 0.08

Whether weary or unweary, O man, do not rest,
Do not cease your single-handed struggle.
Go on, do not rest.
-- An old Gujarati hymn

Ok you had me going there. Ignore previous statements of mine!

The Channel to copy from is Channel 4 which does have listings

So select serviceid,chanid,channum,sourceid,callsign,deleted,xmltvid
from channel where callsign like("Channel 4");

+-----------+--------+---------+----------+-----------+---------------------+---------+
| serviceid | chanid | channum | sourceid | callsign? |
deleted???????????? | xmltvid |
+-----------+--------+---------+----------+-----------+---------------------+---------+
|????? 9211 |? 19211 | 60001?? |??????? 0 | Channel 4 | 2020-11-19
12:25:08 |???????? |
|????? 9211 |? 65692 | 113???? |??????? 1 | Channel 4 |
NULL??????????????? |???????? |
|????? 9212 |? 65693 | 60024?? |??????? 1 | Channel 4 |
NULL??????????????? |???????? |
|????? 9213 |? 65694 | 60025?? |??????? 1 | Channel 4 |
NULL??????????????? |???????? |
|????? 9214 |? 65695 | 60026?? |??????? 1 | Channel 4 |
NULL??????????????? |???????? |
|????? 9216 |? 65696 | 60027?? |??????? 1 | Channel 4 |
NULL??????????????? |???????? |
|????? 8320 |? 65827 | 60150?? |??????? 1 | Channel 4 |
NULL??????????????? |???????? |
+-----------+--------+---------+----------+-----------+---------------------+---------+
7 rows in set (0.001 sec)
So the chanid to use is the undeleted ones of the above.

I see I have your choice of 19211 marked as deleted so its probably no
longer used.


_______________________________________________
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 Sun, 5 Sept 2021 at 10:31, Steve Evans <mythtv-users@gorbag.com> wrote:

>
> Maybe one of them has the deleted field set and is the one with
> an xmltvid value. Try running the query
>
> select serviceid,chanid,channum,sourceid,callsign,deleted,xmltvid from
> channel where callsign like("%Channel 4 HD%") ;
>
>
Aha! Well guessed! This one seems to be hitting paydirt!

mysql> select serviceid,chanid,channum,sourceid,callsign,deleted,xmltvid
from

-> channel where callsign like("%Channel 4 HD%") ;

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

| serviceid | chanid | channum | sourceid | callsign | deleted
| xmltvid |

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

| 21200 | 22200 | 21200 | 1 | Channel 4 HD | 2021-04-13
22:25:17 | hd.channel4.com |

| 21200 | 31200 | 21200 | 1 | Channel 4 HD | NULL
| |

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

2 rows in set (0.00 sec)

So what's the proper fix going forward?
I'm guessing: deleting the chanid 22200 line manually from the database (or
perhaps via mythweb) and adding xmltvid hd.channel4.com to the other line?

On Sun, 5 Sept 2021 at 10:25, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

>
> >BTW is there any significance to the fact that chanid and channum are not
> >the same? Should they be? What's the difference between the two?
>
> Chanid is an internal database index number generated automatically by
> the channel scanning process. It is required to be unique. Channum
> is the channel number used by the user to change to a channel in live
> TV or the guide. There can be multiple channels with different chanid
> values that have the same channum. For example, you may get the same
> channel in HD from a DVB-T2 source, in SD from DVB-T and also from a
> satellite or cable service. To distinguish between the different
> channels with the same channum, the highest priority one will be used
> first. You can set priority in quite complex ways, but usually you
> will have higher priority for the HD versions of channels, either by
> setting the channel table priority entry or by giving the DVB-T2
> source higher priority.


Thank you: this clarifies things a bit.

I'm still not quite sure I understand why I would want to assign channums
by myself. Is it so that (e.g.) BBC1 is number 1, BBC2 is number 2 and so
forth, instead of having to deal with five-digit chanids?

Also, I can't quite understand why I might want to retain several copies of
the same channel under the same channum. Wouldn't it be simpler and less
confusing to delete all of them except the HD one?

On Sun, 5 Sept 2021 at 11:01, UB40D <ub40dd@googlemail.com> wrote:

> So what's the proper fix going forward?
> I'm guessing: deleting the chanid 22200 line manually from the database
> (or perhaps via mythweb) and adding xmltvid hd.channel4.com to the other
> line?
>

In the spirit of "make before break" I've just done the latter but not the
former. I have then re-run mythfilldatabase and it seems to work, although
I need to check more thoroughly before declaring victory. Anyway, thank you
very much Steve!

On 05/09/2021 11:06, UB40D via mythtv-users wrote:
> On Sun, 5 Sept 2021 at 10:25, Stephen Worthington <stephen_agent@jsw.gen.nz>
> wrote:
>
>>
>>> BTW is there any significance to the fact that chanid and channum are not
>>> the same? Should they be? What's the difference between the two?
>>
>> Chanid is an internal database index number generated automatically by
>> the channel scanning process. It is required to be unique. Channum
>> is the channel number used by the user to change to a channel in live
>> TV or the guide. There can be multiple channels with different chanid
>> values that have the same channum. For example, you may get the same
>> channel in HD from a DVB-T2 source, in SD from DVB-T and also from a
>> satellite or cable service. To distinguish between the different
>> channels with the same channum, the highest priority one will be used
>> first. You can set priority in quite complex ways, but usually you
>> will have higher priority for the HD versions of channels, either by
>> setting the channel table priority entry or by giving the DVB-T2
>> source higher priority.
>
>
> Thank you: this clarifies things a bit.
>
> I'm still not quite sure I understand why I would want to assign channums
> by myself. Is it so that (e.g.) BBC1 is number 1, BBC2 is number 2 and so
> forth, instead of having to deal with five-digit chanids?
>
> Also, I can't quite understand why I might want to retain several copies of
> the same channel under the same channum. Wouldn't it be simpler and less
> confusing to delete all of them except the HD one?
>
Normally the channum is (in the UK, at least) taken from the on-air data. For Freeview it gives
repeatable low numbers which remain (mostly) the same even when the channel moves.

You might need more than one version of the channel for when you get scheduling conflicts: If a
transport is is use, say, which is recording from another channel (eg BBC 4 HD) and blocking the HD
version of Channel 4 HD then it will use the priority list to determine if there is an alternative
so that both recordings can progress. If not, it will look at the /program/ priorities and schedule
the lower one at a later time - if it can.

--

Mike Perkins

_______________________________________________
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 Sun, 5 Sept 2021 at 09:23, John <jksjdevelop@gmail.com> wrote:

> I too converted cross-eit to use Python 3 and it is currently working fine
> for me.
>
> I have to edit the file when the clocks change as the line
>
> date = dateobj + datetime.timedelta(seconds=time.altzone)
>
> doesn't cope with the time change, do you have a fix?
>
>
>
While looking for errors, I just noticed the following line in my latest
mythfilldatabase log:

2021-09-05 11:10:35.405331 W No explicit time zone found, guessing
implicit UTC! Please consider enhancing the guide source to provide
explicit UTC or local time instead.

So perhaps a cleaner fix than the hack I suggested earlier might be to
supply the time zone in the exported xml file. It will take a bit of
digging around to figure out two things:

1 - How / where / in what format

2 - What the correct time zone should be. If I have to say UTC+0 in winter
and UTC+1 in summer then I still need that IF statement. I am not aware of
a way of saying "the time zone is whatever is current in the UK, so please
go and look it up in some library that the OS surely has". Or perhaps
that's what "local time" means, if I can figure out a way of saying that in
the xml file.

On Sun, 5 Sep 2021 10:18:15 +0100, you wrote:

>On Sun, 5 Sept 2021 at 10:06, UB40D <ub40dd@googlemail.com> wrote:
>
>>
>>
>> On Sun, 5 Sept 2021 at 09:21, Stephen Worthington <
>> stephen_agent@jsw.gen.nz> wrote:
>>
>>>
>>> The list archive site is now here:
>>>
>>> https://lists.archive.carbon60.com/mythtv/
>>>
>>> but it does not seem to have your Python 3 version of cross-eit.py,
>>> and Google does not find it either. So please repost it, and I will
>>> have a go running it and see if I can see anything.
>>>
>>
>> Thanks. I reposted it now (with headers from the original message, showing
>> that the new list archive is missing at least that post and probably
>> others).
>>
>
>Actually it bounced: held for moderation because of message length.
>So, meanwhile, here is a pastebin of just the script.
>
>https://pastebin.com/d51VUASq

Ok, I have played around with your cross-eit.py and I do not like at
all the way it creates huge line lengths. That can be a problem for a
program trying to read data into a buffer - maybe mythfilldatabase is
having that problem. So I have modified it to use the lxml library
instead of xml, and used lxml's pretty printing output option. I have
put it on my web server:

http://www.jsw.gen.nz/mythtv/cross-eit.py

If you do not already have the lxml package installed, on Ubuntu you
can install it with:

apt install python3-lxml

or it can be installed using pip.
_______________________________________________
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 Sun, 5 Sep 2021 11:21:40 +0100, you wrote:

>On Sun, 5 Sept 2021 at 09:23, John <jksjdevelop@gmail.com> wrote:
>
>> I too converted cross-eit to use Python 3 and it is currently working fine
>> for me.
>>
>> I have to edit the file when the clocks change as the line
>>
>> date = dateobj + datetime.timedelta(seconds=time.altzone)
>>
>> doesn't cope with the time change, do you have a fix?
>>
>>
>>
>While looking for errors, I just noticed the following line in my latest
>mythfilldatabase log:
>
>2021-09-05 11:10:35.405331 W No explicit time zone found, guessing
>implicit UTC! Please consider enhancing the guide source to provide
>explicit UTC or local time instead.
>
>So perhaps a cleaner fix than the hack I suggested earlier might be to
>supply the time zone in the exported xml file. It will take a bit of
>digging around to figure out two things:
>
>1 - How / where / in what format
>
>2 - What the correct time zone should be. If I have to say UTC+0 in winter
>and UTC+1 in summer then I still need that IF statement. I am not aware of
>a way of saying "the time zone is whatever is current in the UK, so please
>go and look it up in some library that the OS surely has". Or perhaps
>that's what "local time" means, if I can figure out a way of saying that in
>the xml file.

The timezone data is added on each timestamp, so on each "start=" and
"stop=" in the XML file. Here is an example from my New Zealand
FreeviewHD data today:

<programme channel="aljazeera.freeviewnz.tv" start="20210905000000
+1200" stop="20210905003000 +1200">
<title>The Bottom Line</title>
<desc>G Host Steve Clemons asks former CDC director Tom Frieden
about where humanity stands in the fight against coronavirus.</desc>
<episode-num system="dd_progid">45899218</episode-num>
<rating system="Freeview">
<value>G</value>
</rating>
</programme>

New Zealand is 12 hours ahead of UTC on standard time, and 13 hours
ahead on daylight saving time, so during daylight saving the "+1200"
changes to "+1300" For the UK, I would suggest using "+0000" for
standard time and "+0100" for daylight saving time. If that field is
present, at the changeover between standard and daylight saving time,
an XMLTV file may have timestamps that have overlapping times, but do
not actually overlap when the timezone setting is taken into account.
_______________________________________________
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 Sun, 05 Sep 2021 22:36:20 +1200, you wrote:

>On Sun, 5 Sep 2021 11:21:40 +0100, you wrote:
>
>>On Sun, 5 Sept 2021 at 09:23, John <jksjdevelop@gmail.com> wrote:
>>
>>> I too converted cross-eit to use Python 3 and it is currently working fine
>>> for me.
>>>
>>> I have to edit the file when the clocks change as the line
>>>
>>> date = dateobj + datetime.timedelta(seconds=time.altzone)
>>>
>>> doesn't cope with the time change, do you have a fix?
>>>
>>>
>>>
>>While looking for errors, I just noticed the following line in my latest
>>mythfilldatabase log:
>>
>>2021-09-05 11:10:35.405331 W No explicit time zone found, guessing
>>implicit UTC! Please consider enhancing the guide source to provide
>>explicit UTC or local time instead.
>>
>>So perhaps a cleaner fix than the hack I suggested earlier might be to
>>supply the time zone in the exported xml file. It will take a bit of
>>digging around to figure out two things:
>>
>>1 - How / where / in what format
>>
>>2 - What the correct time zone should be. If I have to say UTC+0 in winter
>>and UTC+1 in summer then I still need that IF statement. I am not aware of
>>a way of saying "the time zone is whatever is current in the UK, so please
>>go and look it up in some library that the OS surely has". Or perhaps
>>that's what "local time" means, if I can figure out a way of saying that in
>>the xml file.
>
>The timezone data is added on each timestamp, so on each "start=" and
>"stop=" in the XML file. Here is an example from my New Zealand
>FreeviewHD data today:
>
><programme channel="aljazeera.freeviewnz.tv" start="20210905000000
>+1200" stop="20210905003000 +1200">
> <title>The Bottom Line</title>
> <desc>G Host Steve Clemons asks former CDC director Tom Frieden
>about where humanity stands in the fight against coronavirus.</desc>
> <episode-num system="dd_progid">45899218</episode-num>
> <rating system="Freeview">
> <value>G</value>
> </rating>
></programme>
>
>New Zealand is 12 hours ahead of UTC on standard time, and 13 hours
>ahead on daylight saving time, so during daylight saving the "+1200"
>changes to "+1300" For the UK, I would suggest using "+0000" for
>standard time and "+0100" for daylight saving time. If that field is
>present, at the changeover between standard and daylight saving time,
>an XMLTV file may have timestamps that have overlapping times, but do
>not actually overlap when the timezone setting is taken into account.

And for the purposes of cross-eit.py, MythTV uses only UTC internally.
Mythfilldatabase will convert local times to UTC when it reads XMLTV
data. So all cross-eit.py need to do is to add " +0000" to the end of
each "start=" and "stop=" field and that should make that warning
message go away. In any case, it is just a warning and can be ignored
as mythfilldatabase is correctly assuming that the timestamps are UTC.
_______________________________________________
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 Sun, 5 Sept 2021 at 11:26, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

>
> Ok, I have played around with your cross-eit.py and I do not like at
> all the way it creates huge line lengths. That can be a problem for a
> program trying to read data into a buffer - maybe mythfilldatabase is
> having that problem. So I have modified it to use the lxml library
> instead of xml, and used lxml's pretty printing output option. I have
> put it on my web server:
>
> http://www.jsw.gen.nz/mythtv/cross-eit.py
>
> If you do not already have the lxml package installed, on Ubuntu you
> can install it with:
>
> apt install python3-lxml
>
> or it can be installed using pip.


Thank you, much appreciated. I also didn't like those long lines.

(BTW: "your" cross-eit.py is crediting me for more than I deserve, although
I know that's not what you meant.)

I'll use "your" cross-eit.py ;-) as the base when fixing the daylight time
offset issue.

On Sun, 5 Sept 2021 at 11:36, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> The timezone data is added on each timestamp, so on each "start=" and
> "stop=" in the XML file. Here is an example from my New Zealand
> FreeviewHD data today:
>
> <programme channel="aljazeera.freeviewnz.tv" start="20210905000000
> +1200" stop="20210905003000 +1200">
> <title>The Bottom Line</title>
> <desc>G Host Steve Clemons asks former CDC director Tom Frieden
> about where humanity stands in the fight against coronavirus.</desc>
> <episode-num system="dd_progid">45899218</episode-num>
> <rating system="Freeview">
> <value>G</value>
> </rating>
> </programme>
>
> New Zealand is 12 hours ahead of UTC on standard time, and 13 hours
> ahead on daylight saving time, so during daylight saving the "+1200"
> changes to "+1300" For the UK, I would suggest using "+0000" for
> standard time and "+0100" for daylight saving time. If that field is
> present, at the changeover between standard and daylight saving time,
> an XMLTV file may have timestamps that have overlapping times, but do
> not actually overlap when the timezone setting is taken into account.
>

Thank you for the format example and for the caveat. I'll bear them in mind.

On Sun, 5 Sept 2021 at 11:46, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> And for the purposes of cross-eit.py, MythTV uses only UTC internally.
> Mythfilldatabase will convert local times to UTC when it reads XMLTV
> data. So all cross-eit.py need to do is to add " +0000" to the end of
> each "start=" and "stop=" field and that should make that warning
> message go away. In any case, it is just a warning and can be ignored
> as mythfilldatabase is correctly assuming that the timestamps are UTC.


Err... either I can't understand what you are saying or some part of the
above is factually incorrect (or maybe does not apply to my setup).

I have experimentally observed the listings produced by cross-eit causing
recordings to miss one hour (either at the start or at the end, depending
on the direction of the mistake) if the one-line fix by John was not
applied at the right time of year.

On 06/09/2021 07:09, UB40D via mythtv-users wrote:
> On Sun, 5 Sept 2021 at 11:46, Stephen Worthington <stephen_agent@jsw.gen.nz>
> wrote:
>
>> And for the purposes of cross-eit.py, MythTV uses only UTC internally.
>> Mythfilldatabase will convert local times to UTC when it reads XMLTV
>> data. So all cross-eit.py need to do is to add " +0000" to the end of
>> each "start=" and "stop=" field and that should make that warning
>> message go away. In any case, it is just a warning and can be ignored
>> as mythfilldatabase is correctly assuming that the timestamps are UTC.
>
>
> Err... either I can't understand what you are saying or some part of the
> above is factually incorrect (or maybe does not apply to my setup).
>
> I have experimentally observed the listings produced by cross-eit causing
> recordings to miss one hour (either at the start or at the end, depending
> on the direction of the mistake) if the one-line fix by John was not
> applied at the right time of year.
>
It may depend on how your system clock is set. Have you configured it for UTC or for local time? If
the latter, then I would expect to see the effects you describe.

Whenever I install a new system (which is far too frquently these days) hardware RTC setting is one
of the questions Debian asks. All my boxes are set to UTC. I have no problems displaying times
according to local requirements and I have never had any issues with mythtv.

--

Mike Perkins

_______________________________________________
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

Just to muddy the waters a bit, I did do some work a while ago to update
the python script to use python3 and to use the services api. I also sorted
out some of the problems with incorrect times and the like.

I've put a copy here https://pastebin.com/0tQFPBRB

It'll tell you what it does:
$ python3 cross-eit2.py -h
usage: cross-eit2.py [-h] [--debug] [--digest <user:pass>] [--forcehd]
[--host <hostname>] [--output <file>] [--port <port>]
[--shift <time shift>] [--version]
chanidN,xmlidN [chanidN,xmlidN ...]

Fetch EPG data for specified channels from a mythtv database and export this
data to an XMLTV formatted XML file

positional arguments:
chanidN,xmlidN list of chanid & xmlid pairs e.g. chanid1,xmlid1
chanid2,xmlid2 chanidN,xmlidN

optional arguments:
-h, --help show this help message and exit
--debug turn on debug messages (False)
--digest <user:pass> digest username:password
--forcehd forces all output programmes to be flagged as HD
(False)
--host <hostname> backend hostname (localhost)
--output <file> output XML file name (./output.xml)
--port <port> port number of the Services API (6544)
--shift <time shift> time in minutes to move programme data (0)
--version show program's version number and exit

Default values are in ()s


So for channel4HD I take the data from chaniid 18312 which is my Channel4+1
and invoke it like this:
/usr/bin/python3 /home/mythtv/scripts/cross-eit2.py
--output=/tmp/export.xml --forcehd --shift -60 18312,ch4.guide >
/home/mythtv/scripts/cross-eit2.out

and then I run mythfilldatabase like this:
/usr/bin/mythfilldatabase -v --loglevel debug --file --sourceid 1 --xmlfile
/tmp/export.xml > /home/mythtv/scripts/mythfilldatabase.out


I was going to do some more work on it but of course once I'd got it
working something else came along and it got sidelined. Still, it might
help someone out...

Cheers

On Mon, 30 Dec 2019 at 12:40, John <jksjdevelop@gmail.com> wrote:

> On 29/12/2019 18:10, UB40D wrote:
>
>
>
> On Sun, 29 Dec 2019 at 16:37, John <jksjdevelop@gmail.com> wrote:
>
>> On Freesat Channel 4 HD does indeed have no EIT
>>
>
> Argh! Weird and unexpected, but this explains things!
>
>
>> One solution is to copy the EIT from channel 4 using
>> https://www.mythtv.org/wiki/Cross-eit.py
>>
>> I run this once a day using cron
>>
>
> Thanks very much for this tip.
>
> I have managed to extract a channel number for channel 4 as follows:
>
> mysql -u tv -p mythconverg -e "SELECT chanid,callsign from channel WHERE
> callsign='Channel 4'"
> Enter password:
> +--------+-----------+
> | chanid | callsign |
> +--------+-----------+
> | 10211 | Channel 4 |
> | 10212 | Channel 4 |
> | 10213 | Channel 4 |
> | 10214 | Channel 4 |
> | 10216 | Channel 4 |
> | 9320 | Channel 4 |
> +--------+-----------+
>
> (I have no idea why I have so many; this happens with several other
> channels too, even when I restart from a clean scan)
>
> Anyway, I plugged the first of these numbers into a command line for
> cross-eit, as follows, and I managed to produce an xml file:
>
> ./cross-eit.py -o /tmp/export.xml "10211,Channel 4 HD"
>
> ...and I confirm the file had stuff that looked sensible; however I was
> not able to import it into the database. What I tried was
>
> mythfilldatabase --refresh-all --verbose xmltv --file --sourceid 1
> --xmlfile /tmp/export.xml
> ****************************************************
> WARNING: --refresh-all has been deprecated
> use --refresh instead
> ****************************************************
>
> 2019-12-29 18:02:24.010591 C mythfilldatabase version: fixes/29
> [v29.1-40-g951f1fe] www.mythtv.org
> 2019-12-29 18:02:24.010611 C Qt version: compile: 5.5.1, runtime: 5.9.5
> 2019-12-29 18:02:24.010615 N Enabled verbose msgs: general xmltv
> 2019-12-29 18:02:24.010627 N Setting Log Level to LOG_INFO
> 2019-12-29 18:02:24.021071 I Bypassing grabbers, reading directly from
> file
> 2019-12-29 18:02:24.021656 I Setup Interrupt handler
> 2019-12-29 18:02:24.021671 I Setup Terminated handler
> 2019-12-29 18:02:24.021679 I Setup Segmentation fault handler
> 2019-12-29 18:02:24.021689 I Setup Aborted handler
> 2019-12-29 18:02:24.021713 I Setup Bus error handler
> 2019-12-29 18:02:24.021723 I Setup Floating point exception handler
> 2019-12-29 18:02:24.021731 I Setup Illegal instruction handler
> 2019-12-29 18:02:24.021743 I Setup Real-time signal 0 handler
> 2019-12-29 18:02:24.021754 I Setup Hangup handler
> 2019-12-29 18:02:24.021801 I Added logging to the console
> 2019-12-29 18:02:24.021877 N Using runtime prefix = /usr
> 2019-12-29 18:02:24.021881 N Using configuration directory =
> /home/tv/.mythtv
> 2019-12-29 18:02:24.021959 I Assumed character encoding: en_GB.UTF-8
> 2019-12-29 18:02:24.022298 N Empty LocalHostName.
> 2019-12-29 18:02:24.022304 I Using localhost value of sgrizzo
> 2019-12-29 18:02:24.022350 I Start up testing connections. DB localhost,
> BE , attempt 0, status dbAwake
> 2019-12-29 18:02:25.039701 N Setting QT default locale to en_US
> 2019-12-29 18:02:25.039709 I Current locale en_US
> 2019-12-29 18:02:25.039766 N Reading locale defaults from
> /usr/share/mythtv//locales/en_us.xml
> 2019-12-29 18:02:25.043599 I Loading en_gb translation for module
> mythfrontend
> 2019-12-29 18:02:25.044414 I Current MythTV Schema Version (DBSchemaVer):
> 1348
> 2019-12-29 18:02:25.046092 I MythCoreContext::ConnectCommandSocket():
> Connecting to backend server: 127.0.0.1:6543 (try 1 of 1)
> 2019-12-29 18:02:25.046909 I MythCoreContext::CheckProtoVersion(): Using
> protocol version 91 BuzzOff
> 2019-12-29 18:02:25.047055 I Opening blocking connection to master backend
> 2019-12-29 18:02:25.049521 I Starting process manager
> 2019-12-29 18:02:25.049530 I Starting process signal handler
> 2019-12-29 18:02:25.050315 I Starting IO manager (write)
> 2019-12-29 18:02:25.050524 I Starting IO manager (read)
> 2019-12-29 18:02:25.559565 W No explicit time zone found, guessing
> implicit UTC! Please consider enhancing the guide source to provide
> explicit UTC or local time instead.
> 2019-12-29 18:02:25.618284 N Unknown xmltv channel identifier: Channel -
> Skipping channel.
> 2019-12-29 18:02:25.618303 I Updated programs: 0 Unchanged programs: 0
> 2019-12-29 18:02:25.619910 I Adjusting program database end times.
> 2019-12-29 18:02:25.620058 I 0 replacements made
> 2019-12-29 18:02:25.620061 I Marking generic episodes.
> 2019-12-29 18:02:26.047229 I Found 0
> 2019-12-29 18:02:26.047235 I Extending non-unique programids with
> multiple parts.
> 2019-12-29 18:02:26.115452 I Found 0
> 2019-12-29 18:02:26.115458 I Fixing missing original airdates.
> 2019-12-29 18:02:26.381737 I Found 0 with programids
> 2019-12-29 18:02:26.558699 I Found 0 without programids
> 2019-12-29 18:02:26.558707 I Marking repeats.
> 2019-12-29 18:02:26.937490 I Found 0
> 2019-12-29 18:02:26.937497 I Unmarking new episode rebroadcast repeats.
> 2019-12-29 18:02:26.959418 I Found 0
> 2019-12-29 18:02:28.289978 I Marking episode first showings.
> 2019-12-29 18:02:32.714980 I Found 75686
> 2019-12-29 18:02:32.714987 I Marking episode last showings.
> 2019-12-29 18:02:37.053638 I Found 60974
> 2019-12-29 18:02:37.063622 I
> ===============================================================
> | Attempting to contact the master backend for rescheduling. |
> | If the master is not running, rescheduling will happen when |
> | the master backend is restarted. |
> ===============================================================
> 2019-12-29 18:02:37.064193 N mythfilldatabase run complete.
> 2019-12-29 18:02:37.064245 I Waiting for threads to exit.
>
>
> ...but at the end of that I did not find data for Channel 4 HD in the
> database. What I did was
>
> manage recordings / schedule recordings / search lists / channels /
> Channel 4 HD
>
> and it came up with just the current programme, nothing else.
>
> Interestingly, in the box with the names of the channels, it appeared as
> 21200 Channel 4 HD
>
> So I tried the whole rigmarole again but with that number in, as in
>
>
> ./cross-eit.py -o /tmp/export.xml "10211,21200 Channel 4 HD"
>
> mythfilldatabase --refresh-all --verbose xmltv --file --sourceid 1
> --xmlfile /tmp/export.xml
>
> but it still didn't do me any good.
> What am I missing?
>
>
> I vaguely remember the result being one hour offset, presumably it doesn't
>> handle the clocks changing correctly.
>>
>> This line may need attention
>>
>> date = dateobj # + datetime.timedelta(seconds=time.altzone)
>>
> Thanks. I' ll look into that once I manage to import some schedule data...
>
>
> _______________________________________________
> mythtv-users mailing listmythtv-users@mythtv.orghttp://lists.mythtv.org/mailman/listinfo/mythtv-usershttp://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
> There are more than one instance of Channel 4 due to the regional
> versions, you can look up yours on
>
>
> https://en.kingofsat.net/freqs.php?&pos=28.2E&standard=All&ordre=freq&filtre=Clear
>
> Did you follow this step as described in cross-eit
>
> If you want to import the EPG data from the xml file using
> mythfilldatabase, you must add the appropriate xmltvid for each channel you
> want to import EPG to in mythweb [2] as well as uncheck the useonairguide
> for these channels.
>
> Using the mythweb settings - TV - Channel Info
>
> Set the xmltvid to Channel 4 HD
>
>
>
>
> _______________________________________________
> 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
>

Oh, and I pressed SEND too soon....

On Wed, 8 Sept 2021 at 12:11, nemo <myth797@gmail.com> wrote:

> Just to muddy the waters a bit, I did do some work a while ago to update
> the python script to use python3 and to use the services api. I also sorted
> out some of the problems with incorrect times and the like.
>
> I've put a copy here https://pastebin.com/0tQFPBRB
>

...because I also wanted to mention that I was not able to run that:

$ ./cross-eit-nemo.py --output export-nemo.xml 19211,"hd.channel4.com"

19211 hd.channel4.com


No matching channels found.



whereas the same parameters work for the other two versions of cross-eit,
so it's not that 19211 is not in the database or anything like that:


$ ./cross-eit-jsw21.py -o export-jsw21.xml 19211,"hd.channel4.com"

cross-eit v2.1


Processing channel number: 19211, XMLTV id: hd.channel4.com

Number of processed programs: 590


Writing XMLTV EPG information to file export-jsw21.xml





What else am I getting wrong here?



>

Is that channel set to be visible?

I think I found the API didn't return data if it wasn't, which is why I use
the +1 channel and timeshift it.

On Sun, 12 Sept 2021 at 21:22, UB40D via mythtv-users <
mythtv-users@mythtv.org> wrote:

> Oh, and I pressed SEND too soon....
>
> On Wed, 8 Sept 2021 at 12:11, nemo <myth797@gmail.com> wrote:
>
>> Just to muddy the waters a bit, I did do some work a while ago to update
>> the python script to use python3 and to use the services api. I also sorted
>> out some of the problems with incorrect times and the like.
>>
>> I've put a copy here https://pastebin.com/0tQFPBRB
>>
>
> ...because I also wanted to mention that I was not able to run that:
>
> $ ./cross-eit-nemo.py --output export-nemo.xml 19211,"hd.channel4.com"
>
> 19211 hd.channel4.com
>
>
> No matching channels found.
>
>
>
> whereas the same parameters work for the other two versions of cross-eit,
> so it's not that 19211 is not in the database or anything like that:
>
>
> $ ./cross-eit-jsw21.py -o export-jsw21.xml 19211,"hd.channel4.com"
>
> cross-eit v2.1
>
>
> Processing channel number: 19211, XMLTV id: hd.channel4.com
>
> Number of processed programs: 590
>
>
> Writing XMLTV EPG information to file export-jsw21.xml
>
>
>
>
>
> What else am I getting wrong here?
>
>
>
>> _______________________________________________
> 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 Mon, 13 Sept 2021 at 10:12, nemo <myth797@gmail.com> wrote:

> Is that channel set to be visible?
>

No: to reduce clutter in the scheduling screens I have laboriously made all
channels not visible except those few HD channels I might actually want to
record anything from. (This is one thing that needs to be redone when
rescanning, one reason why I don't like rescanning.)


>
> I think I found the API didn't return data if it wasn't, which is why I
> use the +1 channel and timeshift it.
>

Is it correct to infer that cross-eit-nemo would work if I made that 19211
channel visible? Let's try...
...yes! Thank you!

Might be worth improving the error message to something like "No matching
VISIBLE channels found".

Glad it worked for you and I've tweaked the error message in the pastebin
file.

There might be a flag somewhere to change the behaviour I guess, but for me
that's not for today!


On Mon, 13 Sept 2021 at 11:35, UB40D via mythtv-users <
mythtv-users@mythtv.org> wrote:

>
>
> On Mon, 13 Sept 2021 at 10:12, nemo <myth797@gmail.com> wrote:
>
>> Is that channel set to be visible?
>>
>
> No: to reduce clutter in the scheduling screens I have laboriously made
> all channels not visible except those few HD channels I might actually want
> to record anything from. (This is one thing that needs to be redone when
> rescanning, one reason why I don't like rescanning.)
>
>
>>
>> I think I found the API didn't return data if it wasn't, which is why I
>> use the +1 channel and timeshift it.
>>
>
> Is it correct to infer that cross-eit-nemo would work if I made that 19211
> channel visible? Let's try...
> ...yes! Thank you!
>
> Might be worth improving the error message to something like "No matching
> VISIBLE channels found".
> _______________________________________________
> 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
>