Seems like this topic is big enough to be its own page with a summary and hyper links here.

+

* [[Configuring TV output]] is a start

+

* [[HDMI]]

+

* [[User_Manual:Setting_Up#Connecting_your_display]] has some infomration

+

+

There are probably others -- [[Ghormann]] -- 04/17/2011

−

Description: when I purchased Digital Cable service from my cable provider that made it clear that the movie channels, On Demand Channels, and Music channels can only be accessed through the receiver box that they rent to me.

+

== When using live TV, why is there a delay between the moment I change the channel and the time the channel actually changes? ==

−

If I go with MythTV or any other kind of Home Theater PC I'd like to remove that requirement.

:I was fascinated to see this yesterday and am quite confused that it has now vanished (without explanation). Any useful tips to improve channel change time would be most welcome - a hint as to how to do it and any caveats would also be useful.

−

Typically, no. If you have digital cable, the only way to receive the stations is through the receiver box. The good news is, most receiver boxes can be controlled by myth, either via serial, usb, firewire, or an IR Blaster. SOME digital cable users say that they can also receive analog stations off the same cable....but I would expect that number to be dropping as everyone is moving to digital.

+

:Thanks, Alastair

−

This sort of question should probably go on the FAQ page, somebody should add it when we finish the FAQ page

+

::I'd have happily opened up this idea to discussion in the proper place (here). If there are known issues with this idea then they can also be documented here and removed if necessary. I'd like to see some input from the remover "Wagnerrp" with some justifications for removal ... [[User:Eponymous|Eponymous]] 13:11, 15 January 2013 (UTC)

−

== [[User:Beirdo]] has a good FAQ list ==

+

:::It was removed because it was a stupid suggestion. MythTV doesn't use some form of short rolling buffer for Live TV, it records the whole thing, and then keeps it, just like a scheduled recording. It doesn't start a new file until you change channels, or a new show starts. That means if you're trying to watch something long, say a movie or sporting event, you're looking at tens of gigabytes worth of ramdisk. If you are running a server-grade system with registered memory, such that you have a system actually capable of handling enough memory to be able to provide a ramdisk that large, surely you could afford a disk with the minimal amount of throughput necessary to manage one recording. Since you had all that memory available, the recording would still be available through Linux's disk cache, so you wouldn't even need to read it back off the disk.

−

If you go to http://mythtv.beirdo.ca/wiki/index.php/FAQ, you will find a pretty well started FAQ list. Should we enlist Beirdo to either copy or move his material over here? Or perhaps link back to his site? --[[User:Gregturn|Gregturn]] 05:39, 21 January 2006 (UTC)

+

:::Channel changing takes a long time because there are a bunch of things that needs to fall in place for it to occur, and unless you're foolishly running your database on the same physical disk as you're recording to, your filesystem really has little to do with the delay. You need to actually tune the tuner, and many tuners take some time to settle. Once you start receiving data from the tuner, you have to wait for the stream headers necessary to find the channel you want in the stream. Then you have to wait for the first I-frame before you actually have somewhere you can start playback from. On ATSC, this is typically half a second. On some DVB sources, this can be several seconds. Everything up to this point is outside of MythTV's control. MythTV's own contribution to the delay is on the order of two seconds, and is a result of its fundamental design. The frontend and the backend are split, often even on different physical systems, and video data is pulled by the frontend, rather than pushed by the backend. That means there is uncertainty in how much forward data is actually available to the player. A two second buffer is a simple way to ensure the frontend never runs out of data, impacting playback. As you try to reduce the length of this buffer, it becomes increasingly more difficult to prevent stalls and other anomalies in playback that would be more detrimental to user enjoyment than shorter channel change times. [[User:Wagnerrp|wagnerrp]] 15:46, 15 January 2013 (UTC)

−

== Merging to this article ==

−

(brought over from [[Talk:Official Faq]]

−

Baylink, I can begin to manually bring it over if the idea is that the FAQ will end up officially residing here? David, thoughts? Also, is this a FAQ or is it the official documentation, because on mythtv.org it is listed as "Documentation".--[[User:Steveadeff|Steveadeff]] 19:35, 19 January 2006 (UTC)

+

::::So next time, add something to this effect in the comment before removing it blindly or document here why it was removed. This is a collaborative wiki and you're showing poor etiquette. Also refrain from flippant remarks please. I added that comment in good faith and you're just showing yourself up.

−

: Since [[Frequently Asked Questions]] is already cooking, can we focus our energy on that one? I don't know if there is much here that is salvageable. --[[User:Gregturn|Gregturn]] 23:53, 28 February 2006 (UTC)

+

::::[http://www.mythtv.org/wiki/Mailing_List_etiquette#Be_nice Be nice] is as appropriate here as it is on the mailing lists. [[User:Eponymous|Eponymous]] 18:20, 15 January 2013 (UTC)

I can't scan DVB-S card, or even import channels.conf!

(And I see "DiSEqCDevTree, Error: No root device tree node!" in the output)
A: Go to the card's settings in mythtv-setup, and configure DiSEqC. If you don't use DiSEqC switch, set it's type to LNB, default settings.

I wanted to post my own question to this page, without being so bold as to directly edit the page in case that would be deemed to be improper etiquette.

How do I remove recordings that no longer exist on disk?

Is that manual step with the script still needed? It seems that removing recordings which no longer have files associated to them works just fine by default.

When using live TV, why is there a delay between the moment I change the channel and the time the channel actually changes?

I was fascinated to see this yesterday and am quite confused that it has now vanished (without explanation). Any useful tips to improve channel change time would be most welcome - a hint as to how to do it and any caveats would also be useful.

Thanks, Alastair

I'd have happily opened up this idea to discussion in the proper place (here). If there are known issues with this idea then they can also be documented here and removed if necessary. I'd like to see some input from the remover "Wagnerrp" with some justifications for removal ... Eponymous 13:11, 15 January 2013 (UTC)

It was removed because it was a stupid suggestion. MythTV doesn't use some form of short rolling buffer for Live TV, it records the whole thing, and then keeps it, just like a scheduled recording. It doesn't start a new file until you change channels, or a new show starts. That means if you're trying to watch something long, say a movie or sporting event, you're looking at tens of gigabytes worth of ramdisk. If you are running a server-grade system with registered memory, such that you have a system actually capable of handling enough memory to be able to provide a ramdisk that large, surely you could afford a disk with the minimal amount of throughput necessary to manage one recording. Since you had all that memory available, the recording would still be available through Linux's disk cache, so you wouldn't even need to read it back off the disk.

Channel changing takes a long time because there are a bunch of things that needs to fall in place for it to occur, and unless you're foolishly running your database on the same physical disk as you're recording to, your filesystem really has little to do with the delay. You need to actually tune the tuner, and many tuners take some time to settle. Once you start receiving data from the tuner, you have to wait for the stream headers necessary to find the channel you want in the stream. Then you have to wait for the first I-frame before you actually have somewhere you can start playback from. On ATSC, this is typically half a second. On some DVB sources, this can be several seconds. Everything up to this point is outside of MythTV's control. MythTV's own contribution to the delay is on the order of two seconds, and is a result of its fundamental design. The frontend and the backend are split, often even on different physical systems, and video data is pulled by the frontend, rather than pushed by the backend. That means there is uncertainty in how much forward data is actually available to the player. A two second buffer is a simple way to ensure the frontend never runs out of data, impacting playback. As you try to reduce the length of this buffer, it becomes increasingly more difficult to prevent stalls and other anomalies in playback that would be more detrimental to user enjoyment than shorter channel change times. wagnerrp 15:46, 15 January 2013 (UTC)

So next time, add something to this effect in the comment before removing it blindly or document here why it was removed. This is a collaborative wiki and you're showing poor etiquette. Also refrain from flippant remarks please. I added that comment in good faith and you're just showing yourself up.

Be nice is as appropriate here as it is on the mailing lists. Eponymous 18:20, 15 January 2013 (UTC)