mythtv in gutsy does not work when started at boot

Bug #194085 reported by ullix
2
Affects Status Importance Assigned to Milestone
mythtv (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

i have mythtv installed on gutsy such that this backend serves mythfrontend on this and other computers. I have one single DVB-T card. However, when mythbackend is started by the /etc/init.d script (the boot default) all frontends report the error message "all available inputs taken..." although no frontend is actually using any.

When I stop the mythbackend by the command "sudo /etc/init.d/mythtv-backend stop", and then start it with "mythbackend" or as demon with "mythbackend -d" then any frontend can connect properly, be it via ethernet or wlan!

Stopping the mythfrontend, and then killing the mythbackend and restarting it with "sudo /etc/init.d/mythtv-backend start" results in the non-working condition again.

What is happening?

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Bug 194085] Re: mythtv in gutsy does not work when started at boot

Sounds like a permissions problem. Look in /var/log/mythtv for a
mythbackend.log.

On Thu, Feb 21, 2008 at 3:59 PM, Wouter Stomp <email address hidden> wrote:

> ** Changed in: mythtv (Ubuntu)
> Sourcepackagename: None => mythtv
>
> --
> mythtv in gutsy does not work when started at boot
> https://bugs.launchpad.net/bugs/194085
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to mythtv in ubuntu.
>

--
Mario Limonciello
<email address hidden>

Revision history for this message
ullix (ullix) wrote :

Mario, if this is a permission problem and mythbackend.log is telling me about it, it is pretty well disguised. I am attaching the log (with comments in the file).

I can't see it, what does it say about permissions? Any advice where to look?

If there are permission problems, isn't it strange that they are NOT a problem when I start mythbackend as a regular user (one who is in the mythtv group) but not when I start it as a demon, where - I would think - the program is started as the user mythtv?

Revision history for this message
Mario Limonciello (superm1) wrote :

ullix wrote:
> Mario, if this is a permission problem and mythbackend.log is telling me
> about it, it is pretty well disguised. I am attaching the log (with
> comments in the file).
>
> I can't see it, what does it say about permissions? Any advice where to
> look?
>
> If there are permission problems, isn't it strange that they are NOT a
> problem when I start mythbackend as a regular user (one who is in the
> mythtv group) but not when I start it as a demon, where - I would think
> - the program is started as the user mythtv?
>
> ** Attachment added: "mythbackend.log.with_comments"
> http://launchpadlibrarian.net/12156047/mythbackend.log.with_comments
>
Only difference I see is the EIT data scan when run as a user. Check that the
"mythtv" user is a member of whatever group that device is, and that the mythtv
user (not necessarily group) can write to your recordings location. I dont see
the tell tale signs in that log of a permissions problem, but the symptoms fit it.

--
Mario Limonciello
<email address hidden>

Revision history for this message
ullix (ullix) wrote :

I forgot to state: I am using the Kubuntu desktop.

I have no idea what EIT is, and there is no device of this name or a similar one under /dev there is no group with even a faint similarity to EIT. I also verified that the mythtv user can write to the recording location.

There is more strange stuff: The mythtv user and group exist only as system user:group(112:120), and the user had been inactivated (must have come from installation default since I never touched that), although a home directory for mythtv had been created under /home. I activated user mythtv, and went through the same tests again --> Identical behaviour as originally reported.

I rebooted the computer and started the main user session with no myth-anything running. Then I started a new parallel session as user mythtv and started "mythbackend" in the konsole. No error message, and basically same output to the konsole as shown in a previous posting. But when trying live TV the "all inputs taken ..." message came up. Switching over to the other session with the main user resulted in the same failure.

However, starting "mythbackend" in the konsole in the main user session allowed both the main user and mythtv user to watch live TV in their respective sessions!

Then from the main user (mythtv user has no admin rights) I killed mythbackend and started it with "sudo /etc/init.d/mythtv-backend start" : both main user and mythtv user received the error message of "all inputs taken...".

More odd behaviour:
when mythbackend was started in the konsole, then attempting to stop it via "sudo /etc/init.d/mythtv-backend stop" yields the message "Stopping MythTV server: mythbackend No /usr/bin/mythbackend found running; none killed." and mythbackend remains running.
When following with command "sudo /etc/init.d/mythtv-backend start" the script pretends to start mythbackend, but the PID of mythbackend is left unchanged. But when the same command is issued again, then it returns the message "mythbackend already running, use restart instead."

Are the mythtv scripts in init.d not actually testing the running status but maintaining flags somewhere? Are similar flags also the reason for the "all inputs taken..." errors?

Revision history for this message
Mario Limonciello (superm1) wrote :

ullix wrote:
> I forgot to state: I am using the Kubuntu desktop.
>
> I have no idea what EIT is, and there is no device of this name or a
> similar one under /dev there is no group with even a faint similarity to
> EIT. I also verified that the mythtv user can write to the recording
> location.
>
> There is more strange stuff: The mythtv user and group exist only as
> system user:group(112:120), and the user had been inactivated (must have
> come from installation default since I never touched that), although a
> home directory for mythtv had been created under /home. I activated user
> mythtv, and went through the same tests again --> Identical behaviour as
> originally reported.
>
> I rebooted the computer and started the main user session with no myth-
> anything running. Then I started a new parallel session as user mythtv
> and started "mythbackend" in the konsole. No error message, and
> basically same output to the konsole as shown in a previous posting. But
> when trying live TV the "all inputs taken ..." message came up.
> Switching over to the other session with the main user resulted in the
> same failure.
>
> However, starting "mythbackend" in the konsole in the main user session
> allowed both the main user and mythtv user to watch live TV in their
> respective sessions!
>
> Then from the main user (mythtv user has no admin rights) I killed
> mythbackend and started it with "sudo /etc/init.d/mythtv-backend start"
> : both main user and mythtv user received the error message of "all
> inputs taken...".
>
> More odd behaviour:
> when mythbackend was started in the konsole, then attempting to stop it via "sudo /etc/init.d/mythtv-backend stop" yields the message "Stopping MythTV server: mythbackend No /usr/bin/mythbackend found running; none killed." and mythbackend remains running.
> When following with command "sudo /etc/init.d/mythtv-backend start" the script pretends to start mythbackend, but the PID of mythbackend is left unchanged. But when the same command is issued again, then it returns the message "mythbackend already running, use restart instead."
>
> Are the mythtv scripts in init.d not actually testing the running status
> but maintaining flags somewhere? Are similar flags also the reason for
> the "all inputs taken..." errors?
>
My next recommendation to further debug this issue is to add more verbose flags
to the file /etc/default/mythtv-backend. You can get the flags supported from

mythbackend --help

See exactly why Myth thinks these inputs are in use from the init script.

--
Mario Limonciello
<email address hidden>

Revision history for this message
ullix (ullix) wrote :

Well, that is easier said than done, at least for me: I would have to modify the init.d script to add the flags because these are the ones, which don't work. But within those scripts a start-stop-daemon is used to launch mythbackend, and I have no idea how to provide the flags to mythbackend via this demon.

If you can help me with a modified script, I will happily test it.

Revision history for this message
laga (laga) wrote :

ullix schrieb:
> Well, that is easier said than done, at least for me: I would have to
> modify the init.d script to add the flags because these are the ones,
> which don't work. But within those scripts a start-stop-daemon is used
> to launch mythbackend, and I have no idea how to provide the flags to
> mythbackend via this demon.
>
> If you can help me with a modified script, I will happily test it.
>

Check /etc/default/mythtv-backend

Changed in mythtv:
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
ullix (ullix) wrote :

Aaaah, yet another location where things can be modified for mythtv!

But indeed, by changing one line in /etc/default/mythtv-backend to 'EXTRA_ARGS="--verbose all" ' I got me the numerous messages, which helped to uncover the problem and some bugs in mythtv.

Here is the problem: At the start mythbackend does a couple of sql queries of the type 'SELECT data FROM settings WHERE value = 'xyz' AND hostname = 'abc' . Depending on who started mythbackend - user mythtv if started from the scripts under /etc/init.d, and user main if started directly - a different abc was used: for user mythtv it was the real hostname of the computer, for user main it was a name defined in file ~/.mythtv/mysql.txt in line 'LocalHostName='. However, the entry here was what I had given to the frontend on this computer (hoping that it would allow me to distinguish between my multiple frontends) not the backend. Since this was NOT the hostname of any computer, several queries failed and the defaults were taken. Which resulted in a correct dataset and everything worked! But the user mythtv did not have a similar mysql.txt file, and the correct hostname was used, which somehow resulted in a wrong data set, and the message "all input are taken ..." comes up and it did not work.

I think it is a bug in mythtv when mythBACKend uses definitions given for mythFRONTend in attempting to define its BACKend settings. And why is there even a sql query if the defaults allow proper operation? And why does mythtv allow multiple users to start it, but then isn't aware of all the locations where configuration files of the different users are stored and of their content?

I "solved" my problem by sql updating all rows in table settings by changing all hostname='abc' into hostname=NULL where a port or IP was defined, and strangely enough it worked.

Allowing different users then results in additional problems: there is a file nfslockfile.lock in the recordings directory, which seems to be used as a flag since it is always empty (and is never removed), but does not allow a different user to overwrite it. Why not put this flag in the database? But if you leave it, as long as different users are permitted to start the backend, they all have to be able to set this flag.

Looking into other mythtv forums I come to the conclusion that mythtv desperately needs an option to completely reset all database tables and configuration files to their fresh-install state, maybe in mythtv-setup, as there are too many corners where things can be set (wrongly).

Revision history for this message
Mario Limonciello (superm1) wrote :

Unfortunately (in your case) this is the way things are designed. It's the exact reason that LocalHostName isn't recommended and will cause a lot of troubles. With the Hardy builds, this should be a lot less likely to occur. For all users ~/.mythtv/mysql.txt is a symlink to /etc/mythtv/mysql.txt. This means you change it in one place, it's updated everywhere.

Changed in mythtv:
status: Incomplete → Fix Released
Revision history for this message
ullix (ullix) wrote :

If something causes "a lot of troubles" as you say, and I can see in the forums that I am far from being the only one who mistook this, wouldn't it be wiser to remove a not solidly implemented option that to recommend not to use it?

Revision history for this message
Mario Limonciello (superm1) wrote :

It would be, but that is something that would be upstream's decision. There are several very useful cases for LocalHostName, but it needs to be properly used. With that said, its a lot easier to properly use on 8.04, and it should be fairly difficult to run into this corner case.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.