mythtv31 and schedules Direct
Moderator: Forum Moderators
mythtv31 and schedules Direct
First let me state that I love mythtv and have been using it for years. It took awhile to learn to install but was worth the effort. I can't say that about release 31 and how it handles schedules Direct. Another high learning curve for a 74 year old user. Sad to say but how are you going to get a average user to install 31 and SD. Your not.
Re: mythtv31 and schedules Direct
I agree. I spent a good part of yesterday fumbling around with it, and I consider myself quite technically competent. I did get get it (seemingly) working in the end, with a test installation, but after a lot of confusion and frustration. I'm not yet sure when I'm going to tackle upgrading my "production" instance. I found the wiki page vague and confusing - as if written by someone who understands the inner workings but didn't really consider the typical end-user who doesn't, and there's too much "jumping in and out" (do this in mythtv-setup, then do this using the grabber setup scripts, then ...)
Not complaining - just sharing my observation/agreement.
Not complaining - just sharing my observation/agreement.
Re: mythtv31 and schedules Direct
The wiki by its nature is largely user generated content. If you think it's vague and confusing then help to update it so it's not
Re: mythtv31 and schedules Direct
I may do that.
Is there official documentation on implementing SD with XMLTV, and the transition process from DataDirect, somewhere else, then?
Is there official documentation on implementing SD with XMLTV, and the transition process from DataDirect, somewhere else, then?
Re: mythtv31 and schedules Direct
I'm not aware of any official documentation other than the wiki. If there is one thing devs don't like it's doing documentation so it's left to the users to fill in the gaps
I did look to see if I still had the notes from when I had to switch to SD from the RadioTimes grabber when it went defunct but unfortunately it is so long ago it's long since been nuked and I can't remember the details sorry.
We are well aware setting up MythTV needs attention and should be a lot easier. The problem is it's something most of us do once and then forget about it. It should be compulsory for every dev to do a clean setup once a year to remind them how difficult it can be sometimes
I did look to see if I still had the notes from when I had to switch to SD from the RadioTimes grabber when it went defunct but unfortunately it is so long ago it's long since been nuked and I can't remember the details sorry.
We are well aware setting up MythTV needs attention and should be a lot easier. The problem is it's something most of us do once and then forget about it. It should be compulsory for every dev to do a clean setup once a year to remind them how difficult it can be sometimes
Re: mythtv31 and schedules Direct
Thanks for the developers reply on this thread. Like I stated before I think Myth is a great program and much thanks to the developers work.
Resolved my problem by installing myth29 back-end on a unused nuc and after reading about the settings was able to get
schedules direct working on Kodi and Ubuntu 20.04. Temp fix for now, but works.
Thanks again
Resolved my problem by installing myth29 back-end on a unused nuc and after reading about the settings was able to get
schedules direct working on Kodi and Ubuntu 20.04. Temp fix for now, but works.
Thanks again
Re: mythtv31 and schedules Direct
FWIW, I decided to "take the plunge" yesterday, and upgraded to 0.31. I decided to delete my channels and re-scan, rather than try to edit the existing ones with new XMLTV references. This worked OK, once I got the XMLTV grabber configured properly (I'm using the SQLite variant). I did lose the channel references for all of my past recordings, but I don't really care. No other apparent issues so-far. Will see if new recordings (using existing schedules) work tonight. "Upcoming Recordings" in MythWeb looks right, so I'm hopeful.
Re: mythtv31 and schedules Direct
One thing which is not clear from the wiki is how to handle installations like the rpmfusion build on Fedora. There the mythtvbackend runs under a system user account (mythtv) which does not have a login shell enabled and does not have a home directory.
I ran mythfilldatabase after switching over to the new Schedules Direct format, but from the messages it was using the configuration files in my .mythtv and .xmltv directories. When the backend tries to collect new entries in the future it will not have a configuration file available. The instructions in the wiki seem to assume that the mythbackend is running from a user account with a home directory.
Am I correct in assuming that the first time mythbackend attempts to fill new schedule info on its own the grabber is
either not going to run, or will run and crash out right away because it can't find the configuration file?
I had never paid attention to how the schedule information was collected with older versions, but presumably it was all internal to mythbackend because I do not recall ever having to configure an external program to collect schedule information in the past.
I ran mythfilldatabase after switching over to the new Schedules Direct format, but from the messages it was using the configuration files in my .mythtv and .xmltv directories. When the backend tries to collect new entries in the future it will not have a configuration file available. The instructions in the wiki seem to assume that the mythbackend is running from a user account with a home directory.
Am I correct in assuming that the first time mythbackend attempts to fill new schedule info on its own the grabber is
either not going to run, or will run and crash out right away because it can't find the configuration file?
I had never paid attention to how the schedule information was collected with older versions, but presumably it was all internal to mythbackend because I do not recall ever having to configure an external program to collect schedule information in the past.
Re: mythtv31 and schedules Direct
Just a wag, create a mythtv user account and copy the files there so it can find them.
wes@mythfe0:~$ ls /home/mythtv/.mythtv
3rdParty channels MythBrowser MythNetvision themes
cache config.xml MythMusic sd.xmltv tmp
wes@mythfe0:~$ ls /home/mythtv/.mythtv
3rdParty channels MythBrowser MythNetvision themes
cache config.xml MythMusic sd.xmltv tmp
BE/FE-Asrock AB350 Pro Ryzen 3 3200G, 6 atsc tuners. FE's-GF8200's Athlon II, Ryzen 3 2200G. Mythtv user since 2005.
Re: mythtv31 and schedules Direct
mythfilldatabase should run the xmltv script with args "--config-file <mythtv_config_dir>/<source_name>.xmltv". So long as that is accessible to the user running mythfilldatabase (along with any related files - such as the sqlite DB, if you go that route), I think it should work.ccaudle wrote: ↑Fri Apr 17, 2020 1:34 amOne thing which is not clear from the wiki is how to handle installations like the rpmfusion build on Fedora. There the mythtvbackend runs under a system user account (mythtv) which does not have a login shell enabled and does not have a home directory.
I ran mythfilldatabase after switching over to the new Schedules Direct format, but from the messages it was using the configuration files in my .mythtv and .xmltv directories. When the backend tries to collect new entries in the future it will not have a configuration file available. The instructions in the wiki seem to assume that the mythbackend is running from a user account with a home directory.
Am I correct in assuming that the first time mythbackend attempts to fill new schedule info on its own the grabber is
either not going to run, or will run and crash out right away because it can't find the configuration file?
I had never paid attention to how the schedule information was collected with older versions, but presumably it was all internal to mythbackend because I do not recall ever having to configure an external program to collect schedule information in the past.
Edit: further - ongoing (daily) updates are handled by a periodic HouseKeeperTask, which runs mythfilldatabase (or at least the equivalent) and should use the same config path
Re: mythtv31 and schedules Direct
I built myth31 from source on Fedora 31 have my backend run as a service. Thus after enabling it it will auto start after reboots, power fails, etc. I keep my actual service file on mythtv's home so I remember, years from now (I was on 27 last!), when I next upgrade the magic this file does.
Enjoy!
Be sure to systemctl enable mythtvbackend
Enjoy!
Code: Select all
[root@optimyth system]# pwd
/usr/lib/systemd/system
[root@optimyth system]# ls -l mythtvbackend.service
lrwxrwxrwx 1 root root 34 Apr 7 00:22 mythtvbackend.service -> /home/mythtv/mythtvbackend.service
[root@optimyth system]# cat mythtvbackend.service
[Unit]
Description=MythTV Backend Service
After=network.target mysqld.service
Wants=httpd.service
[Service]
User=mythtv
Environment=HOME=/home/mythtv
StandardOutput=null
PIDFile=/home/mythtv/mythtvbackend.pid
ExecStart=/usr/local/bin/mythbackend --daemon --logpath /home/mythtv/logs --loglevel debug --pidfile /home/mythtv/mythtvbackend.pid
Type=forking
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGTERM
Restart=always
RestartSec=15
[Install]
WantedBy=multi-user.target
[root@optimyth system]#
Re: mythtv31 and schedules Direct
A not so obvious point I failed to bring up in my previous post is that mythtvbackend.service will run, as I have it configured, as mythtv not root.
Re: mythtv31 and schedules Direct
I just commented here: viewtopic.php?f=36&t=3745&p=17980#p17980
regarding the use of MYTHCONFDIR rather than HOME.
Also, side light, please use: systemctl cat mythtv-backend (or any .service/.timer/... .) That way if
there's an override file, it will be printed in addition to the one in lib. Local changes belong in an
override file. That way if the distribution releases a new version of the service, your changes won't
get removed. see systemctl edit. It does the proper placement/permissions/daemon-reload for you.
regarding the use of MYTHCONFDIR rather than HOME.
Also, side light, please use: systemctl cat mythtv-backend (or any .service/.timer/... .) That way if
there's an override file, it will be printed in addition to the one in lib. Local changes belong in an
override file. That way if the distribution releases a new version of the service, your changes won't
get removed. see systemctl edit. It does the proper placement/permissions/daemon-reload for you.
Re: mythtv31 and schedules Direct
Having just gone through the process of setting up Schedules Direct with XMLTV myself, I have to agree with the original poster here. I too have been using MythTV for years. While setup and configuration has always been a little more involved than I like, I figured I can't complain for a free, open-source product. I'm not sure I'd say that now. While the documentation was a bit confusing, I was able to get through it and appear to have been successful... but I would have definitely given up very quickly if I were a new user. With Data Direct, entering my username and password for SD in the backend setup was simple. For XMLTV, it was a much more involved process that required careful attention.
Why was it necessary to drop support for Data Direct? Surely it could have remained supported until a much more streamlined process for setting up XMLTV could be built into the backend config. And yes, I know I can downgrade if I don't like it, but... I just feel like that shouldn't be necessary.
Why was it necessary to drop support for Data Direct? Surely it could have remained supported until a much more streamlined process for setting up XMLTV could be built into the backend config. And yes, I know I can downgrade if I don't like it, but... I just feel like that shouldn't be necessary.
Re: mythtv31 and schedules Direct
Well, they did have dual support for a while. I upgraded to the new grabber while on mythtv 30 because I saw support for dd would be dropped in 31. But still, the change could have been emphasized more, or at least a warning to upgrade the grabber before upgrading to 31 to minimize down time.
Actually, there was a post for that, which has a lot of good information, but again, a more prominent warning before upgrading could have been useful. Maybe it was there and I didn't notice because I'd already upgraded the grabber.