Hi Mike,

Modify /etc/X11/fluxbox/keys and add

Mod1 e :ExecCommand gedit

Then, Alt+e will start gedit without having to resort to an xterm.

Also, you're right about the xterm = dos prompt thing. 99% of people don't want it. Honestly, tjc, ask a typical Windows user what they'd rather do: a) look at a movie and follow the graphical interface instructions or b) use an xterm. I think you'll find that none would go for option b) or they would not be using Windows.

Mike

_________________
*********************
LinHES 7.4
Australian Dragon
*********************

Hi,
I just got back from being away for a few weeks to find some emails indicating there have been some updates to this thread.

If I understand the last few posts, this means that this long running problem has now been solved, is that correct?

I have my fingers crossed that it is

Kevin

Nope not for me it has not

Dechlan,

I see from previous posts you have three dvb cards, have you scanned for channels on each card to see how good each cards reception is. I think if you press either f6 or f7 during live tv it gives you stats like signal strength and BER (bit error rate) if you flip between different cards and compare how long it takes to get a lock, on the right hand side it should come up with LMS i think when you get a full lock.
If the period it takes is too long then you are likely to get this error. This time can vary dramatic even fron the same type of card within the same system. I have two almost identical cards within a few serial no's of each other, end yet i get differing times for a lock on each card. My third source is a usb stick tunner that can take three times as long to get a lock.
The way I minimised the effect of the third card weakness was to generate a seperate source for this card, I removed the weakest channels (the ones it took to long to get a lock) so this card only used for good channels. If you then increase the priority of this card, it will be less likely to be used for live tv, especialy if you check the box saying avoid conflics with live tv.

SimonF

_________________
Running:-
Intel 930 3GHz dual Core
Thermaltake Fanless CPU Cooler
Asus P5GS
Samsung 750G Sata HDD
8400 512m Video Card
2 * jetway DVB-t
1 * Haupage DVB-S2 Card
Samsung Sata 16x DVDRW
2048M Ram
1 * Netop Ion 330

I have 3 cards and the plan was to put all 3 in the box, however since im having issues my test box only has 1 card and the other 2 are in my "live" box (r5a16 !)

I will try f6/f7 and see whati get however.

Darn, that's a real shame. I wonder if any of the MythTV developers are still working on this problem.

BTW, sorry if it's a stupid question, but since the problem (on my system at least) occurs at a program change, how does the time the tuner card takes to tune come into it?
If the tuner is on the same channel, and the program changes does the signal momentarily disappear or something?

thanks,

Kevin

It's been set to fixed in development.

Does the fact that you're still getting the error mean that you've:
1. stopped the backend (Alt+F2)
2. run mythtv-setup (Alt+s)
3. for each of the tuners, disabled "wait for seq start header"
4. quit mythtv-setup
5. restarted the backend (Alt+3)

??

There is a proper fix, but it's not going to be included in KM for a while. Doing the above totally stopped my getting this message.

Mike

_________________
*********************
LinHES 7.4
Australian Dragon
*********************

Hi Mike,

I can't honestly say that I have followed all the steps you listed but it has been a while since I worked on this and it is hard to recall what I have done and what I haven't.

I have been away for a while, and last time I worked on my Myth box I was battling a problem with corrupt OS (possible faulty drive). I only the other day managed to take a backup of the disks (using TrueImage10) and are now ready to start trying to use my Myth box again.

Thanks for outlining the required steps so clearly, I will try do do some testing this evening, if not the weekend,

Kevin

Ok I came up with the "seq headers thing " a month ago or so its not a fix more a fudge. A fudge which seems to have cured the problem for quite a few of us.

It was my supposition that a program break causes the stopping of a recording then the starting of a new recordings. This I imagine is done quite simply by killing one recording and starting another ie back to back recording. So my supposition was that when it starts recording, into the second file mythbackend treats this as a completly new recording i.e. the fact that it is already on that channel makes no difference it still goes throught all the motions of a new recording ie tune find the stream then find the start of a new sequence before the new recording starts. If you try flicking between two channels on the same multiplex you will see what I mean in theory the tuner is already 'tuned into' the correct frequency yet it still take five or six seconds to get a picture up. even though it knows there on the same multiplex, I figure a program break has the same effect IE :-It knows the tunner is on the correct channel (Same Multiplex) {although sometime it may use a different tuner if youve checked the 'avoid clashes with live tv box' } but still has to demux the correct stream and then wait for a sequence header. If you add to this the horrific ammout of processing done by MYSQL in the background ie updating the recordings etc theres no wonder the new file isnt ready to play back by the time the first one has finished.

By unchecking the 'wait for seq headers box' your just reducing the time it takes to do this startup job (also the MYSQL server optimisation also reduces this time) so they are both sort of fixes. Neither an unoptimised MYsql or the delay in for the seq headers or your cards ability to get a timely lock causes this fault BUT if all three added together causes too long a delay you get It. A real fix needs to be done at mythtv by either making one long recording with no program breaks maybe with offsets for the start and finish times of each program within that recording OR the mythbackend to recugnise back to back recordings and when flaged just start recording the next seq headerinto the new file without any break in the stream.

There are lots of developments being made in this area INCLUDING multiple recordings from the same tuner on the same of programs on the one multiplex. I hope this will fix this problem as the new recording could then start B4 the old one has finnished so should be ready in time.

Rgds

SimonF

PS this is all supposition If anyone knows better how program transitions ocour I'de Like to know.

_________________
Running:-
Intel 930 3GHz dual Core
Thermaltake Fanless CPU Cooler
Asus P5GS
Samsung 750G Sata HDD
8400 512m Video Card
2 * jetway DVB-t
1 * Haupage DVB-S2 Card
Samsung Sata 16x DVDRW
2048M Ram
1 * Netop Ion 330

1. stopped the backend (Alt+F2)

Should be....

1. stopped the backend (Alt+2)

Whoops! Sorry 'bout that

_________________
*********************
LinHES 7.4
Australian Dragon
*********************

I just wanted to report that I recorded a day's worth of the MTV Earth Day concert on CTV HD and didn't have a single glitch.

Maybe I should try watching one of the channels where there are lots of program changes but this is the first time I have been able to watch/record so many hours without a problem

Perhaps disabling "wait for seq start header" has made a difference on my box.

Now I just have to wait for the Myth developers to come up with a solution to the zap2it crisis and I would have a box I could actually use! CBD HD (on of the major networks in Canada and one of my most frequently watched channels) recently disappeared from the listings and I don’t expect the zap2it guys are going to be bothered about fixing that for me

I read somewhere that the Myth developers are close to an announcement but there were hints it would need a new version of Myth, but I worry that it will takes months before that will be integrated into KnoppMyth,

Kevin

Well, I'm pleased to say my 3.2 IBM HD Mythbox has also gone 24 hours straight watching 'live TV', without encountering the dread 'error has occurred'.... Never did that before....

The uncheck wait for seq header start' fix above seems to have worked on my hardware.
Thanks, manicmike !....


Hardware: IBM 3.2ghz P4 'Thinkcentre' tower
1gig memory

Two Air2PC 0.2 ATSC cards
Seagate 500gig PATA drive
Streamzap USB remote
Nvidia FX5200 vidcard

You're welcome That error was a killer for Knoppmyth. It's actually been fixed properly in the next mythtv (0.21) but that could be ages away.

Mike

_________________
*********************
LinHES 7.4
Australian Dragon
*********************

There has been a fair bit of activity at ticket 2335 recently re this problem, still plenty of people seeing it in the very latest mythtv versions

http://svn.mythtv.org/trac/ticket/2335

Ive been too busy with work recently to get a chance to look at this but the latest post has a source patch which suggests may help/fix the problem.