tv_grab_zz_sdjson_sqlite second grabber on same DB eliminates some channels on the first

[networks1]

Thanks for taking the time to report an issue. Please take a moment to review our open/closed issues above, in case your issue has already been reported.

If you are reporting a new issue, please give your issue a descriptive title and fill out the blanks below, providing as much information as possible.

XMLTV Version? 0.6.1 …

XMLTV Component? tv_grab_zz_sdjson_sqlite

What happened? When adding second grabber to same DB, some (but not all) channels from the first grabber were removed …

What did you expect to happen? For the channels from the first grabber not to be removed. …

Did you see any warnings/errors? no …

What steps are needed to reproduce this issue? Repeat the setup process with one DB (Please provide the full commands you are running)

1. tv_grab_zz_sdjson_sqlite --manage-lineups --config-file $HOME/.mythtv/cable.xmltv Accept default DB name. Add lineup, initialize/update DB.
2. tv_grab_zz_sdjson_sqlite --configure --config-file $HOME/.mythtv/cable.xmltv Keep lineup asssociated with the grabber (Cox Digital Cable -- Phoenix for first, US OTA 85001 for the second.
3. tv_grab_zz_sdjson_sqlite --days 0 --config-file $HOME/.mythtv/cable.xmltv
4. Do channel selection with sqlite3 queries
5. Repeat 1-3 with ./ota.xmltv and an additional SD lineup

Any other information? For the second grabber in step 1 I added a new lineup. In step 2 I only kept the lineup corresponding to the ota grabber. I was able to get things working on Mythtv by using two different DB names, so I am set. But it seems it should not be necessary to have two DB names given that the DB structure is set up to handle multiple lineups. I'm thinking this might be a bug in tv_grab_zz_sdjson_sqlite

…

What other software are you using?

Operating System: Ubuntu 18.04

Perl Version: v5.26.1

[garybuhrmaster]

That is an invalid reproducer. Direct sqlite commands are not a supported mechanism to manage channel selection, you are expected to use the grabbers configuration capability which implements the business logic. If you can reproduce the issue using the internal selection mechanisms with the latest master (there have been changes in/near that code area with the latest master) please provide the exact commands, lineups, and selections used with the grabber configuration. Thanks.

[networks1]

It's not really practical to use the internal selection command mechanisms. My cable lineup has over 600 channels and it would take a couple hours to type enter or y-e-s enter for each of them. Besides, this channel elimination happened before I made any actual changes to the channel selections, so it should be reproducible without the sqlite cheating. I only used a SELECT * FROM channels to verify that it was happening after starting over because of disappearing channels on an earlier try. Maybe code changes on a more recent version fixed it, as you suggest.

[garybuhrmaster]

Besides, this channel elimination happened before I made any actual changes to the channel selections

As no channels have ever been marked as deselected during the default usage in any version of the grabber, please provide a reproducible test case.

[garybuhrmaster]

so it should be reproducible without the sqlite cheating.

Using a trivial test case using the internal functions managing selected with multiple lineups, sharing a common database, I can not reproduce it. Please provide a reproducible test case without using "sqlite cheating" (as you put it) so that I can reproduce and diagnose the failure. Thanks.

I will say that the entire channel selection code is itself complex and fragile, and likely should be deleted as more trouble than it is worth to deal with for broken applications.

[garybuhrmaster]

Closing this issue. The issue cannot be reproduced with the current master using the supported methods, and the requested reproducer by the original reporter has not been provided.

If a reproducer can be provided please open a new issue at the upstream project.