Re: mythtranscode

Página superior

Responder a este mensaje
Autor: Harry Coin
Fecha:  
A: dmo-discussion
Asunto: Re: mythtranscode
On 1/19/2013 1:05 PM, Ross Boylan wrote:
> On Wed, 2012-12-19 at 08:57 +0100, Christian Marillat wrote:
> ...
>> If I read the Ubuntu packages list, mythtranscode is mandatory for
>> mythtv-backend and mytharchive packages.
>>
> mythtv-backend 0.26.0+fixes20130104-dmo1 depends on transcode, and so
> mythtv-transcode was not installed on my system when I upgraded.
>
> Maybe the dependency needs to be updated.
>
> Ross
>
>


It SO does.  After delaying for a time after .26 came out, I upgraded a 
master backend and two slave backends.   The masterbackend had a 'full 
install' using 'mythtv', the slaves allowed mythbackend to be selected 
without requiring mythv-database (since why run mysqld on slave backends 
for nothing?).   All seemed well through the upgrade.   However, 
suddenly most commercials weren't getting flagged.  Mythcommflag would 
simply hang forever. On one slave lots of 'mythlogserver' jobs would 
stack up, 8, 10, more.    There were dark rumbles online about not 
wanting to touch the depths of ffmpeg where the suspected trouble was.


Finally debugging efforts required launching a xfce session on the
otherwise headless backends, allowing synaptic to run. There browsing
'things myth' mythtranscode wasn't installed, various libxxx debris
from long since upgraded to 0.25 0.24 remained, the latest codecs 0.26
were not installed. So much for 'dist-upgrade'.

Anyhow, choosing to install the otherwise unrequired transcode and
lib... codecs for .26, fixed all commercial detection problems.

Well, almost. There was the matter of all the jobs marked 'commercial
flagged' for which the whole thing was a botch. The mythcommflag
--queue command left out more than it covered. Finally had to write a
batch job that listed all the contents of the recording directories and
fed them to mythcommflag one by one. All good now.

Mythbackend needs to force mythtranscode and the lib... necessary for
mythcommflag to work.

I still think there needs to be 'mythtv-backend-master' and
'mythtv-backend-slave', 'mythtv-frontend' and
'mythtv'=='mythtv-frontend+mythtv-backend-master'. There is no use in
forcing mysql and mythtv-database on slave backends. All it does is
soak up memory and open ports for mysqld for no reason. If you want to
leave a dummy mythtv-backend that points to mythtv-backend-master as a
transitional package ok.

Also in the category of wish list, mythtranscode all by itself should be
everything necessary to do commercial flagging and transcoding jobs
without either the frontend or backend activity.