Date: Fri, 6 Jan 2006 00:13:03 -0500 (EST)
From: "Chris Pinkham" <[EMAIL PROTECTED]>
> (a) The SBE's mythtranscode was getting handed myth:// "URLs" instead
> of just a pointer into the filesystem, then complained that it didn't
> support that mode. Jobs on the MBE ran fine, but that meant that some
> random proportion of them would just error out and die.
In 0.18.x, the myth:// URLs are given if myth can't find the recording
in the same directory path on the local backend as it is on the backend
that recorded the file. In SVN, myth will also check the local
backend's RecordFilePrefix directory for the file and use a local
filename if it exists there, otherwise it falls back to the myth://
URL.
Aha! So in other words, even though I can set the recording directory
path on the SBE in its setup, if it's not exactly the same as on the
master, transcoding fails. This is inconsistent with the way
recording and commflagging work (the commflagger was working on my
SBE, as far as I can tell), but I'll see if I can rearrange my NFS
mounts so the SBE thinks /myth/tv is where recordings live (as the MBE
thinks now), rather than thinking that they live in /mnt/mbe/tv or
(via a symlink) /mnt/tv as they do now. Would a symlink on the SBE
from /myth/tv to /mnt/tv (which will then traverse the mountpoint)
be adequate, or are symlinks themselves going to be problematic?
Incidentally, this particular arrangement was suggested by the
linhes.html page on the KnoppMyth site, which talked about how to set
up slaves; it's not clear to me how those instructions (which can only
be talking about non-SVN versions) could possibly be right in the face
of this transcoding inconsistency.
> (b) It then left all the errors in my job queue for some long period
> of time and nobody could figure out how to actually make them go away.
> (They appear to have all vanished 8 days (yes, not 7) after erroring,
> spontaneously; is there some week-and-a-day timeout somewhere?) This
> was apparent from reading the backend logs, since I've got both
> backends and the frontend logging to files to "-v" and have since
> about 6 weeks ago.
I thought we went over this.
Uh, if we did, it wasn't with me... :)
The 8 days is because in 0.18.x, errors
are kept around for 7 days and the cleanup job only runs once a day,
so the jobs could be around for almost 8 days depending on when they
ran and when the cleanup job ran in the housekeeper. In SVN, this
has been shorted from 7 to 4. I think you could still have deleted
these jobs from the mythfrontend status screen though by using the
popup menu on an errored job.
That seems logical, but nobody who said anything could -find- such a
popup. I couldn't, and (IIRC) Jarod couldn't, either. (I recall
something like, "I could have -sworn- this existed, but I can't find
it now...") My suspicion is that it went into SVN very shortly after
18.1, or something like that.
> (c) The resulting transcoded files had -VERY- low audio levels, and I
> couldn't find any way of making them at least match the originals.
> (My recordings in general -also- have low audio levels, despite
> setting ALSA mixer levels high; is there some way of convincing 250's
> and 350's to record louder? I'm comparing to the TV itself and all
> the other devices which share the cable feed, none of which have this
> problem.)
There is a volume control for ivtv compatible cards right in the
recording profile editor. This has been there since the ivtv
support was added to Myth.
Yeah, I know about that one. It's at 90%. IIRC, I also tried it at
100%, with not much effect. I should probably ask Hans and/or the
ivtv lists if anyone has any ideas there; I'm almost wondering if
the problem isn't ALSA but some register setting in the cards.
(Is there some reason why all the sliders aren't 100% by default?
Would there be distortion issues or something?)
I could -live- with recordings being 6-12dB down from everything else
(though the mystery annoys me), but what I can't deal with is the
transcoded stuff being another ~12dB down from -that-. I had to
peg the TV's volume almost to the very top to get listenable audio,
and that's just wrong. (Not to mention dangerous if I select another
input! :) It's not clear to me at all why transcoding should mess
with any audio levels; does it even have any -inputs- for changing
them? (E.g., is it looking at some ALSA slider for some weird
reason? Does it have command-line args that affect this?)
This was really easy to demonstrate, btw, since I told Myth not to
toss the originals when it transcoded. I could just rename them back
& forth in place of each other and play them; the transcoded ones were
always much quieter.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
