>
> On Mon, 30 Jan 2006 07:14:33 +, MythTV wrote:
> > #549: make 3/9 act as pageup/down in three places that need it
> > Changes (by cpinkham):
> > I really think we should be going the opposite direction with this patch,
> > not adding more places where 3/9 act as pageup/down. If people wa
> >#996: mythjobqueue fails to transition from "stopping" to "finished" if new
> >jobs
> >enter queue
> I've seen something similar that might give someone an idea: I had 40
> programs orso scheduled for transcode. Halfway trough I had to restart
> mythbackend to try a few changes I made. when
> > I'll commit to SVN after 0.19 is released.
>
> I second that request. Is it so significant a change that it can't go in for
> 0.19? (Yes I know there was a feature freeze, but couldn't you slip it past
> Isaac while he isn't looking?)
No. :) It's probably non-intrusive enought to go into 0
> I often view Recordings and then I have the Idea to scheudle another
> program, but i won't leave the recording!
>
> How about Including the epg not only in live TV, although in the view
> recordings???
I have run into this quite a few times also. I'll see an advertisement
for some show I thin
> FYI, if you "jump livetv" and then "play channel " you get "ERROR: You
> are not in playback mode". However, if you enter live tv through the normal
> means the "play channel" commands works fine.
>
> This is svn 8702.
How quickly after the "jump livetv" are you trying to use the "play chan
> > Author: cpinkham
> >Date: 2006-01-22 06:22:57 + (Sun, 22 Jan 2006)
> >New Revision: 8688
> > Changeset: http://cvs.mythtv.org/trac/changeset/8688
> >
> >Added:
> >
> > trunk/mythtv/programs/mythfrontend/networkcontrol.cpp
> > trunk/mythtv/programs/mythfrontend/networkcont
> > Author: cpinkham
> >Date: 2006-01-22 06:22:57 + (Sun, 22 Jan 2006)
> >New Revision: 8688
> > Changeset: http://cvs.mythtv.org/trac/changeset/8688
> Couldn't make that port 6546 could you?. Port 6545 is also the default used
> by Myth to talk to the mythlcdserver.
Sorry abo
> > I also wondered if there is value in fixing the aspect ratio to the
> > height instead of the width (or have the option between the two).
> >
>
> If you have a wide screen aspect ratio TV, you would like to fix
> height and calculate width. If not, you want to fix width and
> calculate he
> 2006-01-18 19:25:48.791 ERROR retrieving program info when trying to delete
> program for chanid 15489 recorded at Wed Jan 18 19:00:26 2006. Recording
> will NOT be deleted.
This is saying that the delete code in mythbackend couldn't load the program
info for the recording from the recorded tabl
> I've logged a select sql which is causing mysql to jump to 100% for upwards
> of 40 seconds which kills anything else needing data. I believe the sql is
> part of the housekeeping thread. Is there anyway of putting a limit on the
> return and putting it in a loop instead of getting the whole thin
> mythtranscode (that I'm aware of), it turns out that myth just doesn't
> count frames in exactly the same way. In addition, the way the index
> is generated in myth isn't very reliable (a cutpoint will happen at a
> different point depending on whether you watch the video from the
> beginning or
> Does anyone know of a document that discusses what changes were made in the
> myth
> protocol from one version to the next? I'm interested because I run svn on my
> backend (protocol 23) but I just got a Roku HD1000 to use as a frontend but
> currently mythroku speaks protocol version 15. I'm
> > > Chris, I believe this is how it has always worked, overrecord is applied
> > > unconditionally to the recording. Then the overrecord time is overridden
> Your right about the old implementation, I had forgotten about the 0.18
> implementation. That code was changed a while ago, I believe to
> > Add a "Preserve Aspect Ratio" option to the Transcoding recording
> This change looks interesting, but I'm not quite sure exactly how it's
> intended to be used, but maybe that's because of how I use
> transcoding?
> And I don't see any weirdness in the aspect ratio of the transcoded
> record
> Chris, I believe this is how it has always worked, overrecord is applied
> unconditionally to the recording. Then the overrecord time is overridden
> by StartRecording() when the scheduler wants to record something. This
> allows the overrecord to work in the presence of rescheduled or canceled
>
> The frontend was doing a terribly slow regexp creation/search sequence
> in TV::GetQueuedChanNum that was soaking 14.6% of the process' CPU
> cycles.
> bool HasQueuedChannel(void) const
> -{ return queuedChanID || !GetQueuedChanNum().isEmpty(); }
> +{ return queuedChanID ||
> Just started playing around with transcoding and noticed the same
> thing. I've setup some transcoding profiles, assigned some recordings
> to them, enabled auto-transcoding after the recording but they don't
> get transcoded (don't even see it come up in the logs). They get
> transcoded when I s
> Boleslaw Ciesielski wrote:
> > --- libs/libmythtv/avformatdecoder.cpp (revision 8519)
> > +++ libs/libmythtv/avformatdecoder.cpp (working copy)
> > @@ -2483,6 +2483,7 @@
> > }
> > if (onlyvideo < 0)
> > {
> > +
> >Comment (by pkahle):
> >
> > This seems to actually be fixed in code, as of revision 8389. Is it worth
> > changing this report to reflect that?
> >
> >
> That's what Bruce Markey's comment (the one before yours) said:
>
> Change repeat to isrepeat in ./libs/libmythtv/datadirect.cpp /or use a
> Since sometime around January 4th, real-time commercial flagging has
> failed to find any breaks.
>
> If the commflagger is started after the show has started to record,
> it works fine.
>
> John
Can you provide some backend logs for when this happens? They might
explain what is going on.
--
> There is now this problem with week change, when it's assigned to the
> same as day change at 00.00, when there's also last weeks reruns coming
> at seventh day. Then we need an addon to the algorithm to record the
> last one coming at the seventh day, which is hopefully the new episode,
> not th
> Maybe the find weekly is acting as it is coded, but there's sure a bug.
> Had a program coming once a week, and it wasn't recorded couse "it was
> already recorded this week" which it wasn't.
I think you're missing the fact that Bruce is saying that the week
starts at the time and day-of-the-wee
> Using libmyth-0.18.1_0.18.1-8_i386.deb on debian unstable downloaded
> Jan 3 09:42. I thought that would have the latest cvs build.
Must not be, that column has been renamed to isrepeat in Head and
-fixes.
--
Chris
___
mythtv-dev mailing list
myt
> Is it possible to quote the word "repeat" using backquotes insite the
> SQL statements in datadirect.cpp? "repeat" is a reserved word in MySQL
> 5 and it's causing me to have to edit libmythtv and recompile everytime
> a new version is released.
> Thanks,
> -Nathan
Don't know what version you'r
> > RE: 941, I think the concensus was to not put things like .spec files
> > in SVN, but I'll let others comment on that.
>
> -1I guess the real problem with .spec files are
> that they are high maintenance, and it is a lot of
> activity for the developers to keep checking in
> changes to kee
> Also, this would be very useful for installing SVN on multiple FE/BE. I
> am not sure how one does that currently without recompiling on each machine.
I have 4 systems that I run Myth SVN on (3 production and 1 development) and
I only compile once. Each system is kept at the same revision leve
> Anyone got a moment to apply a couple of trivial patches into SVN? .. Or
> should I just let them be gotten to whenever someone feels like it?
>
> Trac ticket numbers: 936,938 (both 1 liners), 941 (3 files into contrib).
Normally it's whenever someone gets around to looking at it.
RE: 936,
> After successfully compiling the latest SVN, I noticed that there are not
> jumppoints listed in the MythWeb - Configure Keybindings page. I assume
> that these are from this...correct me if I'm wrong.
>
> If they are, would it be possible to add a MainMenu jumppoint as well?
The three jump po
> Thanks that helped alot. So debugging stuff commflag is correctly finding
> the commercials, but something weird is going on during playback. The
> actual video frames and frame numbers are not matching up between
> mythcommflag and mythfrontend.
>
> In the main recording I have been look
> 8468 didn't fix the issue for me:
> select starttime, endtime, basename from recorded where recgroup =3D
> "LiveTV"order by starttime;
> +-+-+-+
> | starttime | endtime | basename|
> +---
> > Are any of these recordings sticking around and being left un-expired?
> >
> > If so, can you provide the recorded table into to go along with the log?
> >
> > select starttime, endtime from recorded where recgroup = "LiveTV";
>
> That's the mysql output for both files appearing in my log. Bot
> Well, rather than take the easy way out, I decided to try my hand at
> fixing it. Here's what I got:
> Calling TVRec::SetChannel() doesn't result in FinishedRecording()
> getting called.
> The flags at the start of the HandleTuning call are:
> FrontendReady,RunMainLoop,AskAllowRecording,Recorder
> Here's my BE log (mythbackend -v record) where my LiveTV failed to
> start initially and it also failed to change channels on the third
> channel change. And you'll probably be able to see why it sets the
> endtime to the actual show endtime.
Are any of these recordings sticking around and being
> My understanding is that UserJob run once after a recording is finished.
>
> Has any one considered allowing UserJobs to be run at different times per
> recording?
>
> eg: Each UserJob have these options: (each individually selectable)
>
> Run at Start of recording(so I can run MythL
> I'm trying to turn OFF all the commercial flagging.
> In the MythWeb, manual and custom recording, there is a tick box for
> Auto-Commercial flagging. I have worked out that this tick box reflects the
> value in the MySQL database, Settings table, value = 'AutoCommercialFlag'.
>
> However, I c
> I would like to look into some commflag debugging. I see there are
> already bits in place to display/dump frames, but the support functions
> for them dont resolve. I suspect they are defined in commercial_debug.h,
> which is commented out in ClassicCommDetector.cpp but doesnt exist within
> On 12/29/05, Chris Pinkham
> > Do these recordings have the correct endtime on them or is the endtime
> > set to the actual program endtime? If so, the "short" calculation fails
> > since endtime - starttime is greater than one minute.
> Yes, this is
> > Chris, is this commited yet? Sounds like cool functionality. :)
>
> I'll probably wait until after 0.19 is released before I put this into SVN
> unless Isaac gives the go-ahead. The patch I did for Pluto was based off
> of the 0-18-fixes branch so I need to make a few changes to get it
> mer
> 12/30/05 03:33:33: Modified by ghaushe
>
> * status changed from closed to reopened.
> * resolution deleted.
>
> I am still seeing this issue pretty frequently as of 8391. Is there
> some data I can provide that'll help track it down?
Do these recordings have the correct endtime on them or is
'http'
commands to allow controlling this via a web browser. A
'query recordings html' version of a 'query recordings' command
could return html code to draw a page with links something like
'http://hostname:6545/play?program&1031&2005-10-17T22:00:00'.
> 5) it might also be helpful to have mythtv-setup packaged so we can
> setup the backend
This is probably a requirement for using mythjobqueue. The JobQueue is
meant to be run inside mythbackend, so the setup screens for the JobQueue
are inside mythtv-setup. I created the stand-alone mythjobq
> #!/bin/sh
> PRG=$0
> PRG=`dirname $PRG`
> export PATH=$PATH:$PRG
> echo $PATH
> `exec $mythjobqueue_exec`
>
> The original problem that this set out to solve is the jobqueue
> expects the executables for commflag and transcode to be in the
> path. When they are inside the bundle, this is ju
> The last committed change to the mythfilldatabase code is 8218, Chris
> Pinkham's change which deals with the scheduling of mythfilldatabase. Seems
> like a likely culprit ...
>
> I'll take a look at the changes made, perhaps I can even find the problem and
> submit a patch.
This is related
> > You can't disable AutoExpire anymore, that setting went away.
> > If you don't want normal recordings autoexpiring, then don't turn
> > on autoexpire on your scheduled recordings.
> >
>
> Yeah, this is a very old thread...been very busy lately.
>
> Anyhow, what is the reason for forcing peop
> looking at nuppeldecoder, if the nuv file doesnt have an embedded seek
> table, it too will suffer the same problem.
> i.e. if this embedded seek table is corrupt you are stuffed. unless Im
> reading it wrong.
nuppeldecoder uses a variable called hasFullPositionMap. This gets set
to true if t
> yes. it loaded the existing seek table. then erased it. didnt update it as
> it found a valid seek table. then wrote back what it read in the first
> place. thus no change. pretty obvious once you look.
> however if there wasnt a seek table then it worked correctly. which of
> course is only g
> > #781: RebuildSeekTable doesnt
> I'm trying to understand what this bug was, since I've been using
> mythcommflag
> --rebuild quite a bit lately. Did it prevent mythcommflag from rebuilding the
> seek table? is it something I should bother updating from svn and re-run
> mythcommflag for?
I
> I had the same issue with 18.1 and I do not use the svn version, but I
> downloaded it, and saw the code changed.
> The problem I discovered in 18.1 was:
>
> programs/mythfrontend/playbackbox.cpp: 1232 (Release 18.1)
> from
> if
> (gContext->GetNumSetting("UseCategoriesAsRe
> Chris Pinkham and interested persons,
>
> I've been messing with the commercial detector in 18.1 (very similar to svn
> version) to improve detection of Australian ads. Here is what I've found so
> far using the ALL method:
Yeah, I haven't spent much time re
> stdout as well? Note that I'm not using "-l"; I just redirected it via
> the shell. Here's what I've got so far:
>
> Input #0, mpeg, from '/myth/tv/1002_20051207215500_20051207215600.nuv':
> Stream #0.0: Video: mpeg2video, 720x480, 29.97 fps, 6000 kb/s
> Stream #0.1: Audio: mp2, 48000 Hz,
> Chris Pinkham wrote:
> >> I ask because as of changeset [8071] dbcheck is using MySQL 4.1.x+
> >> specific values when creating the initial database which effectively
> >> prevents a new 4.0.x user (and are there any 3.23.x users out there?)
> >
> >
> I ask because as of changeset [8071] dbcheck is using MySQL 4.1.x+
> specific values when creating the initial database which effectively
> prevents a new 4.0.x user (and are there any 3.23.x users out there?)
I think this is going to need to be fixed, I thought we were trying to
maintain 3.
> It would be even better if recordings remembered which cardinput they
> originated from and that info was available from the osd say. Then when I
> get a couple of duff ones it would be much easier to see which card is at
> fault. I think someone else suggested the same thing the other day. Still
> On Mon, 2005-12-05 at 21:37 +0100, Adam Egger wrote:
> > Regarding:
> > Ticket #742 - DVB dummy stream also recorded
> > you said, it's a feature not a bug.
> >
> > This feature unfortunately means for me (and others too) that there're
> > two entries for every recorded show in the recording lis
> This reapplies commit #7990 which was accidentily
> removed in change #8102 breaking compiling with GCC 3.3.4
#signs are for Tickets, and [brackets] are for Changesets. :)
--
Chris
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org
> > Author: danielk
> > Date: 2005-12-05 01:42:37 + (Mon, 05 Dec 2005)
> > New Revision: 8116
> >Changeset: http://cvs.mythtv.org/trac/changeset/8116
> >
> > Modified:
> >
> >trunk/mythtv/libs/libmythtv/osd.cpp
> >
> > Log:
> >
> > Fix compiler warning.
>
> The warnin
> Does "ALL" mean that if the code detects ANY one of the conditions (e.g.,
> logo detection), it marks it? Also, how is logo presence/absence
> determined? Also, what does strict commercial detection do?
Strict makes the checks for blank frames tigher and if you're using
Blank-Frame detection (
> Any ideas people have tried?
Lots of stuff. Seems someone pops up every few months with ideas and
goes off coding, but hardly anyone has submitted code to enhance the
current detection. I think I wrote probably 90% or more of the current
detection code and haven't worked on it in a while since
> > If the backend is running when mythtv-setup is run, send out a
> > CLEAR_SETTINGS_CACHE event when mythtv-setup exits.
>
> does it mean that it is it safe to run mythtv-setup with backend running
> now?
The semi-safeness remains the same, this just means that in case any
safe settings are cha
> 3. The backend log very often shows quite often:
> 2005-11-28 20:15:31.061 MainServer::HandleQueryRecordings()
> Couldn't find backend for:
> Unknown : "Unknown"
> 2005-11-28 20:15:31.069 MainServer::HandleQueryRecordings()
>
>Changeset: http://cvs.mythtv.org/trac/changeset/8073
> Add a "MythWelcomeStartFECmd" setting to mythwelcome to allow you
> to define what command to use to start the FE including any commandline
> parameters to add when mythfrontend is started through mythwelcome.
>
> For the moment you m
> I'm not at the Myth console, but I have access to the DB. Where should
> the LiveTV group be? I don't have one in playgroup, nor in any other
> table that I could find. In playgroup I have only 'Default' and 'tom'
> (which I created last night).
It's a 'LiveTV' Recording Group, not a PlayGrou
> Does this mean live tv files will not get cleaned up if I have
> auto-expire disabled? I do not trust a computer to decide which
> recordings I wish to keep and those I do not. If I miss a recording due
> to lack of space, it's my fault. That is my preference.
You can't disable AutoExpire
> When watching a video-file in MythVideo with the Internal player, I
> noticed this error:
>
> 2005-11-24 00:35:33.260 TV: Attempting to change from None to
> WatchingPreRecorded
> 2005-11-24 00:35:33.348 DB Error (SetInUse):
> Query was:
> INSERT INTO inuseprograms (chanid, starttime, recusage,
> I'm updating on a daily basis, so the revision I'm using now is now ~ 8000.
Can you re-update and run mythbackend with "-v important,file" and see what it
prints out as it goes through expire list in SendDeleteMessages? That may help
me
figure out what's going on. I just added some more debug
> > Here's what I did to get the code working on my system and it's
> > futureproof if we ever add fields to recordmatch.
> This patch works for me.
> (mysqld Ver 4.0.22-log had no problem with the "drop temporary table," but
> seemed happy to drop the non-temp table when given that command, if
> the temp version. I'm also trying to figure out why this screen
> doesn't work in the Titivillus theme, but didn't notice anything,
> but seeing the time maybe it's that I'm too sleepy to debug but
> not too sleepy to code (hence my reason for posting this patch
> for review). :)
OK, maybe I wa
> Wendy Seltzer wrote:
>
> > Duplicate column name 'recordid'
>
> mysqld --version
>
> -- bjm
I see the same here. I think that section of code needs to be
modified no matter what the MySQL version because we're
duplicating the recordmatch schema when we shouldn't be (here
and in dbquery). M
> opinions of expected behaviour, and the available information. In this case a
> misunderstanding resulted from the quotation of Chris:
>
> "I believe that 'R' in LiveTV just toggles whether a recording will be
> saved (by moving it out of the LiveTV group into the default
> recording group),
> I was seeing this last night too, running r7972. I ended up with 20
> or so live-tv recordings that were still there this morning. I exited
If you watched them for more than 1 minute, they should still be there.
> On the last program I was watching, I hit R to have myth record the
> The new autoexpire method doesn't work for the LiveTV recordings on my
> system. I have tons of tiny files in my recording list marked with an
> RIP symbol now.
Doesn't sound like you're running current SVN.
> My autoexpire is turned off globally because I absolutely don't want
> myth to remov
> This time it was, indeed, the case of not running make clean.
> However, other times I have had to make small changes to the code
> which I found strange. Thanks for the list of steps to take. I'l
Because each developer is potentially using a different distribution
(and possbly differe
> fix the problem or I'll get a different error. For example I just
> updated to svn 7963 and when I run make I get this error:
>
> ClassicCommDetector.o(.text+0x241ed): In function
> `ClassicCommDetector::go()':
> ClassicCommDetector.cpp: undefined reference to
> `NuppelVideoPlayer::OpenF
> I apollogize if this is already implemented in SVN, as I'm running 18.1.
> It woud be really nice, to (while watching live tv) change channels in
> Browse mode or "classic" mode, with seperate key bindings. I would like to
> change channels with the Ch+/Ch- keys on my remote, or browse them with
> I apollogize if this is already implemented in SVN, as I'm running 18.1.
> It woud be really nice, to (while watching live tv) change channels in
> Browse mode or "classic" mode, with seperate key bindings. I would like to
> change channels with the Ch+/Ch- keys on my remote, or browse them with
> classes. I'd really appreciate some idea of how to share my work with
> others,
> given that I'm working in a directory that's already a subversion checkout.
> I
> have a subversion server myself - should I make a repo on it, put the files
> in
> there, and then symlink them in the actual
> > I think it's better to use a LiveTV Recording Group, then we can "save"
> I'm sure you and Isaac have already considered these situations, but I
> can't tell from the commits what the result might be and I since my
All in Isaac's head not mine, it's his brainchild. :) I'm just sitting by the
> > Plan is to autoexpire short (probably < under 5 minutes) programs from
> > livetv
> > at a greater frequency than the current autoexpirerer runs through things.
> > Just haven't written it yet.
I think the expiration of LiveTV files before regular recordings is currently
broken because Progra
> >#610: Add a seperate frequency list for US-Cable-IRC
> > Reporter: anonymous| Owner: ijr
> > Type: enhancement | Status: new
> >The IRC frequency standard used by many cable systems differs
> > substantially in the frequencies for channels 5 & 6 (US-Cable values are
>
> 2. Every recording appears twice in my recording list. Has anyone else
> encountered this strange behavior? Is there a way to trace it?
What do you have your view set to? (ie, "Show Titles Only",
"Show Titles and Categories", etc..)
If you're using one with "Categories" in it, then do your the
> > No, i'm not using knoppmyth and i don't have mythfilldatabase running from
> > my crontab.
> > I'm prety sure the status is the same if i run mythfilldatabase manualy and
> > it have something to insert.
>
> FYI: This has been happening to me ever since I've used myth. It has
> never annoyed
> > starttime: 2005-10-11 15:35:00
> >starttime: 2005-10-11 15:34:00
> Looks like one is working off the show starttime and
> the other is working off the startime+preroll.
Should be fixed in SVN now. I was evidently filtering out the
"despite my transcode jobs (entered by pressing x
> On Fri, Oct 14, 2005 at 09:00:35PM -0400, Isaac Richards wrote:
> > Old way was fine, since creating previews is only a one time cost
> > per recording.
>
> Since you mentioned it. My system seems to needlessly regenertate
> previews frequently -- not every time, but frequently enough to be
> n
> I was wrong, the shows are not recorded, but in the tuner status it says at
> the time the program start currently recording.
>
> Also, when I start the backend in a terminal and not as service when a
> program is startet, it displays currently recording bla bla bla.
>
> I hav enough free space
> There isn't a frontend option for mpeg2->mpeg2 transcoding is there? Only a
> command line one? I'd quite like to see this added before 0.19.
You can do it by creating a "MPEG-2" recording profile according to the
commit log:
http://svn.mythtv.org/trac/changeset/7057
Not sure if that lets you
> > Is that code stable enough? I though I'd seen quite a few posts where
> > users were
> That's why I put it out for discussion.
> Guess I have a new target to stabilize for 0.19 :-)
I had forgotten that Aaron McCarthy's patch was applied a couple months back
that rewrote
major parts of the
> With mythtranscode,
>
> Now that we are producing mpg files by default should we
> modify mythtranscode so that if the input file is .mpg
> then we default to mpeg to mpeg transcode???
Is that code stable enough? I though I'd seen quite a few posts where users
were
getting errors with it beca
> didnt think it was worth a ticket.
I mighta noticed that before I did my own quick fix if you had. :)
I don't filter -commits, but dump -dev into it's own mailbox so I end
up reading -commits first.
I committed something similar to this with a comment as to why the
case is empty.
--
Chris
__
> Things like ./configure --cpu --tune --arch give me an error message
> when running configure after getting 7412.
>
> Was this supposed to happen?
Should work now. These options are parsed earlier in the configure
script so they don't need to be parsed in the main option parsing
code that prin
> I was one of the people having autoexpire problems, and I'm going to
> try it out, but I was just wondering, what problem(s) this changed
> supposed to correct? Here's what I've seen myself, or heard reported:
>
> - Recordings deleting when they should not
> - Recordings not deleting when they
> If I try to transcode or commflag, it errors out with these errors in the
> backend log:
>
> 2005-10-03 10:18:20.932 Commercial Flagging Starting for The West Wing "The
> Mommy Problem" recorded from channel 1030 at Mon Oct 3 10:17:00 2005 illegal
> option: '623' (use --help)
Can you run mythba
> I was looking at the houskeeping table in mysql and found:
>
> 'JobQueueCleanup', '2004-10-02 12:51:48'
> 'JobQueueRecover-hostname', '2004-10-02 12:51:48'
> 'MythFillDB', '2005-10-02 04:52:47'
>
> That got me wondering why the dates for JobQueueCleanup and JobQueueRecover
> was so old.
> On Thu 29 September 2005 20:46, Mickey Chandler wrote:
> > At 02:28 PM 9/29/2005, Robert Tsai wrote:
> > >FWIW, you can configure the backend to run mythtranscode *first*
> > >before running mythcommflag.
> >
> > Have I just missed the instructions on how to do that?
>
> It's under mythtv-setu
> Here's what happened.
>
> 1. Started recording a dummy 30 minute commercial recording..
> 2. mythcommflag started up a few moments later.
> I looked at the backend log, there were some new error message I hadn't
> noticed before. They could be due to other issues, I'm not sure.
>
>
> 2005-0
> I can understand mythtranscode deleting the type=6 (the video is no long
> MPEG2, but rather MPEG4 now, so the seek table can be removed, I think?).
>
> Did mythtranscode just wipe out the commercial skip list for the
> recording? Is that my problem or is something else magical happening
> t
> >#381: SegFault in WatchRecordings when setting Recording Group
> Wouldn't it be more intuitive to keep the list in Alphabetic order and
> just highlight/select/move focus to the current recording group?
Yeah, probably could do this with setCurrentItem(). Maybe I use the
Default group more th
> Anyone else have real time mythcommflag fail over the last few days with
> zero commercials being detected? Running various SVN's from the last 4
> days.
>
> Or is it just me.
Check your logs for something like this message:
Unable to find active recorder for this
recording
> I have SVN from about two weeks ago (7206 IIRC) and I'm getting the
> following log on the backend with -v commflag.
Not recent enough. :) I put in a fix in SVN a few days ago to catch
this scenario and print out some more debug into to see if we can
figure out why this is happening. For some
> So, I've been out of the loop for over a year now, and was wondering
> what the status of mythtranscode (specifcally mpeg2trans) was.
Don't think I've messed with the mpeg2trans code any according to
the commit logs.
Main changes I made to the other part were done in order to allow
me to transc
> I think mythtranscode has stopped working (possibly due to this change
> or r7250). I always get this failure:
Actually r7251. :) Should be fixed in SVN now with r7255.
--
Chris
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cg
1 - 100 of 259 matches
Mail list logo
