Difference between revisions of "Talk:Frequently Asked Questions"

From MythTV Official Wiki
Jump to: navigation, search
m (Added follow-up.)
m (Updated ref.)
Line 33: Line 33:
 
:::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)
 
:::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)
  
::::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. [[http://www.mythtv.org/wiki/Contribute]] seems appropriate here. [[User:Eponymous|Eponymous]] 18:20, 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. [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)

Revision as of 18:53, 15 January 2013

This was a major issue for me:

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.

CleanUp: What are my options for connecting my computer to my TV?

Discuss: Frequently_Asked_Questions#What_are_my_options_for_connecting_my_computer_to_my_TV.3F

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

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

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

Any reason why my contributions regarding using a ramdisk were removed? Ref: [1] Eponymous 12:25, 15 January 2013 (UTC)

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)
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)