workaround for systemd with network tuners

[white_haired_uncle]

https://mizar.mythtv.org/wiki/Installin ... _on_Ubuntu references this, I think, in a dead link at the end. There should be a post in the mythtv users email list archives, but as close as I can come searching is another dead link (which shows me just enough that I'm pretty sure it's exactly what I'm looking for).

Basically, systemd starts mythbackend before networking is fully up (seems like enforcing dependencies would be something an init system should be responsible for, but I guess the plan is to take over every other aspect of the system before getting that silly init thing working properly) and someone has a work-around.

There's something at https://mizar.mythtv.org/wiki/Systemd_m ... nitialized, but it's tied to NetworkMangler. I'm looking for a more general fix to update the wiki, if there is one (and no, I don't mean Devuan).

[dnalorernst]

For systemd, there exist two services controlling the network:
- systemd.networkd https://www.freedesktop.org/software/sy ... orkd.html#
- NetworkManager https://networkmanager.dev/

They are incompatible when running together.
Thus, one needs to choose the correct wait-online service:
- systemd-networkd-wait-online.service
- NetworkManager-wait-online.service

[white_haired_uncle]

Thanks. What I'm looking for is the workaround for when systemd fails and starts mythtv too soon. I've seen it posted, but never paid much attention since I don't do systemd. But it's referenced on the wiki with only a dead link, so I figured I'd update it if I can find the workaround.

[heyted]

https://mizar.mythtv.org/wiki/Mythbuntu ... etup_Tasks
https://mizar.mythtv.org/wiki/Hdhomerun_check.py
https://lists.mythtv.org/pipermail/myth ... 04519.html

[white_haired_uncle]

Thanks. That python script looks like what I was looking for. At least I can try to point people in the right direction.

Actually ran into this today in the rpmfusion mythtv packages for fedora. Doesn't help with network tuners, but it's interesting. If I understand it, these create udev rules which create systemd devices which can then be used to delay starting mythbackend until physical capture cards are "ready"(?).

Code: Select all

#/lib/udev/rules.d/99-mythbackend.rules
SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"
SUBSYSTEM=="firewire", TAG+="systemd"

I guess the user would add, for example, "dvb.device" to the "After=" line in mythbackend.service if one had such a thing and wanted mythbackend to start after it became available.

Seems reasonable enough. I'm not sure about the implications of things like removable (USB) capture cards. I know I personally would rather have mythbackend start if I was using such a device but it wasn't available at startup (so I don't miss recordings on my HDHR).

I don't have systemd or a physical capture card to test with (got three PVR-250 remotes in the drawer, but no cards to go with them). Still I wonder if this is something that should be included in the setup instructions.

[heyted]

Thanks for noticing the dead link. Stephen W does a good job of describing the setup on the mailing list. A copy of the web page that the dead link previously went to is available at web.archive.org. I went ahead and edited the Installing MythTV on Ubuntu wiki page and added the corresponding link using the pipermail mailing list archive. I also added a link to the hdhomerun_check.py script. My preference is to use MCP to save time since setting up either script is a bit complicated, and MCP contains both of these scripts (the MCP hdhomerun script will be updated soon).