Mailing List Archive

HDHR prob with new wallwarts
Greetings Mythizens, Because my system does not shut down gracefully
(Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and
still have unreliable recording performance from them. One box failed on
both recordings about ten minutes in, and then the other after 15 minutes,
so I gave the first unit higher priority in my router as well as a fixed
IP, and tested again with similar results. Then after some googling I tried
powering them down for about 15 mins, then testing again, with success. Can
Mythtv reboot these devices prior to putting them to use? I used to wake
the box as needed, but since the mobo doesn't cooperate and the backend is
up before the HDHRs are capable of responding... well you see my situation,
any suggestions? TIA Daryl
Re: HDHR prob with new wallwarts [ In reply to ]
> On Dec 6, 2019, at 2:00 PM, Daryl McDonald <darylangela@gmail.com> wrote:
>
> Greetings Mythizens, Because my system does not shut down gracefully (Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and still have unreliable recording performance from them. One box failed on both recordings about ten minutes in, and then the other after 15 minutes, so I gave the first unit higher priority in my router as well as a fixed IP, and tested again with similar results. Then after some googling I tried powering them down for about 15 mins, then testing again, with success. Can Mythtv reboot these devices prior to putting them to use? I used to wake the box as needed, but since the mobo doesn't cooperate and the backend is up before the HDHRs are capable of responding... well you see my situation, any suggestions? TIA Daryl

The problem Silicondust had with power supplies was a very long time ago—back when the Dual was introduced? While power surges (esp. a lightning strike) can still kill them at any time, SD do not seem to have a systemic problem nowadays with the power supplies failing.

Where did you get replacement power supplies? Are you positive they are the right spec. Silicondust will supply replacement power supplies at a very reasonable cost as a legacy of their previous problems.

Also, if you file a trouble ticket with Silicondust, they can enable logging from the HDhomerun boxes and may be able to offer a solution.

Craig

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDHR prob with new wallwarts [ In reply to ]
On Fri, 2019-12-06 at 14:00 -0500, Daryl McDonald wrote:
> Greetings Mythizens, Because my system does not shut down gracefully
> (Gigabyte mobo that cooperates with windows, but not Ubuntu) I've
> been leaving it on 24/7. I finally got new wallwarts for both of my
> HDHR's and still have unreliable recording performance from them. One
> box failed on both recordings about ten minutes in, and then the
> other after 15 minutes, so I gave the first unit higher priority in
> my router as well as a fixed IP, and tested again with similar
> results. Then after some googling I tried powering them down for
> about 15 mins, then testing again, with success. Can Mythtv reboot
> these devices prior to putting them to use? I used to wake the box as
> needed, but since the mobo doesn't cooperate and the backend is up
> before the HDHRs are capable of responding... well you see my
> situation, any suggestions? TIA Daryl
>
> _______________________________________________mythtv-users mailing
> listmythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

to reboot your hdhr from terminal use:hdhomerun_config "deviceid" set
/sys/restart selfwhere device id is the number of your device which you
can get with: hdhomeurn_config discover
you can make a simple script to trigger it as an event in myth like the
'recording pending' under system events insetup. i find that triggers
usually 30 seconds ahead of a recording. to further refine you would
want to check thatthe tuners are idle to have it not reboot on back to
back scheduled recordings.
Re: HDHR prob with new wallwarts [ In reply to ]
On Fri, 6 Dec 2019 14:00:00 -0500, you wrote:

>Greetings Mythizens, Because my system does not shut down gracefully
>(Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
>leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and
>still have unreliable recording performance from them. One box failed on
>both recordings about ten minutes in, and then the other after 15 minutes,
>so I gave the first unit higher priority in my router as well as a fixed
>IP, and tested again with similar results. Then after some googling I tried
>powering them down for about 15 mins, then testing again, with success. Can
>Mythtv reboot these devices prior to putting them to use? I used to wake
>the box as needed, but since the mobo doesn't cooperate and the backend is
>up before the HDHRs are capable of responding... well you see my situation,
>any suggestions? TIA Daryl

I am not sure rebooting the HDHRs will help. You shut them down,
rather than rebooting. So it could be a temperature problem, and they
cooled down enough while they were off to be able to complete a
recording once they were restarted. So you need to test whether a
reboot is all that is required, or whether they actually need to be
shut down for a while. And you could try just pointing a fan at them
to see if that helps.

Also, what do you mean by "backend is up before the HDHRs are capable
of responding"? Since you are using network tuners, you should have
the fix installed that causes mythbackend to wait until the HDHR
tuners are available before it starts. But if you did not have that
fix, the HDHRs would often not work at all after the box is booted,
until you restarted mythbackend. But that is not the problem you seem
to be describing.

As for the problem with shutting down the motherboard, if it shuts
down in Windows, then it is clearly able to be made to shut down
properly, once you find out what in Ubuntu is causing it not to shut
down. That can be quite difficult, but it is possible. I have had
problems like that, and what I found was the best way to diagnose
shutdown problems was to do this:

sudo systemctl enable debug-shell.service

which enables a root debug console on Ctrl-Alt-F9 that comes up very
early during boot and goes away very late during shutdown. It does
not require a login (as it comes up before logging in is possible) and
hence is a serious security problem when enabled, but it is able to be
used to tell you what is happening when Ubuntu fails to shut down or
shuts down very slowly. Once you have a debug console, then you can
try shutting down. When the shutdown is happening, use Ctrl-Alt-F9 to
go to the debug console and use commands like:

systemctl list-jobs

to see what is still running, what is waiting to be run and so on. You
will normally find one or more jobs that are waiting a long time for
something to happen, such as a network connection to shut down or a
non-existent (network or local) drive to be mounted so that it can be
unmounted.

One thing that catches most MythTV users is the problem that
mythbackend has a shut down bug itself, and fails to shut down
completely when asked to by systemd. Systemd then does a long timeout
before finally killing mythbackend using a kill -9 call. I think that
takes 60 or 90 seconds, and it delays other things from getting shut
down also. What happens in mythbackend is that most of it is shut
down, but at least one thread fails to stop. If it is given a second
normal shutdown request shortly after the first one, it will shut down
immediately then. The fix I have for this problem is to put this line
in the [service] section of your systemd override file for
mythtv-backend:

ExecStop=/usr/local/bin/mythbackendstop.sh

and put a copy of my mythbackendstop.sh file in your /usr/local/bin
directory:

#!/bin/bash
PID=$(systemctl show -p MainPID mythtv-backend.service 2>/dev/null |
cut -d= -f2)
if [ "$PID" != "0" ]; then
kill -15 $PID
sleep 1
kill -15 $PID
fi


which you can do by downloading it from my web server:

sudo su
cd /usr/local/bin
wget http://www.jsw.gen.nz/mythtv/mythbackendstop.sh
chown root:root mythbackendstop.sh
chmod u=rwx,g=rx,o=rx mythbackendstop.sh
exit

It is also a good idea to put these two lines in the [service] section
as well, as a backup in case mythbackend is locked up and really needs
a kill -9:

SendSIGKILL=yes
TimeoutStopSec=10

That will do a kill -9 after 10 seconds if mythbackend still does not
shut down.

My override file for mythbackend is:

/etc/systemd/system/mythtv-backend.service.d/mythtv-backend-override.conf

but yours (if it exists) may have a different name. The name does not
matter as long as it is a .conf file. The easy way to create or edit
one these days (as long as your systemd has been updated) is:

sudo systemctl edit mythtv-backend
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDHR prob with new wallwarts [ In reply to ]
On Fri, Dec 6, 2019 at 2:25 PM Craig Treleaven <ctreleaven@cogeco.ca> wrote:

> > On Dec 6, 2019, at 2:00 PM, Daryl McDonald <darylangela@gmail.com>
> wrote:
> >
> > Greetings Mythizens, Because my system does not shut down gracefully
> (Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
> leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and
> still have unreliable recording performance from them. One box failed on
> both recordings about ten minutes in, and then the other after 15 minutes,
> so I gave the first unit higher priority in my router as well as a fixed
> IP, and tested again with similar results. Then after some googling I tried
> powering them down for about 15 mins, then testing again, with success. Can
> Mythtv reboot these devices prior to putting them to use? I used to wake
> the box as needed, but since the mobo doesn't cooperate and the backend is
> up before the HDHRs are capable of responding... well you see my situation,
> any suggestions? TIA Daryl
>
> The problem Silicondust had with power supplies was a very long time
> ago—back when the Dual was introduced? While power surges (esp. a
> lightning strike) can still kill them at any time, SD do not seem to have a
> systemic problem nowadays with the power supplies failing.
>
> Where did you get replacement power supplies? Are you positive they are
> the right spec. Silicondust will supply replacement power supplies at a
> very reasonable cost as a legacy of their previous problems.
>
> Also, if you file a trouble ticket with Silicondust, they can enable
> logging from the HDhomerun boxes and may be able to offer a solution.
>
> Craig
>

Thanks Craig,the specs only differ in that the new ones have greater
amperage available 3 as opposed to 1, my understanding is that amps will
be supplied as called for by the connect, not by the the spec on the wart.
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Fri, 6 Dec 2019 14:00:00 -0500, you wrote:
>
> >Greetings Mythizens, Because my system does not shut down gracefully
> >(Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
> >leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and
> >still have unreliable recording performance from them. One box failed on
> >both recordings about ten minutes in, and then the other after 15 minutes,
> >so I gave the first unit higher priority in my router as well as a fixed
> >IP, and tested again with similar results. Then after some googling I
> tried
> >powering them down for about 15 mins, then testing again, with success.
> Can
> >Mythtv reboot these devices prior to putting them to use? I used to wake
> >the box as needed, but since the mobo doesn't cooperate and the backend is
> >up before the HDHRs are capable of responding... well you see my
> situation,
> >any suggestions? TIA Daryl
>
> I am not sure rebooting the HDHRs will help. You shut them down,
> rather than rebooting. So it could be a temperature problem, and they
> cooled down enough while they were off to be able to complete a
> recording once they were restarted. So you need to test whether a
> reboot is all that is required, or whether they actually need to be
> shut down for a while. And you could try just pointing a fan at them
> to see if that helps.
>

I'm not so sure either now, another test points to network traffic, what
I've been doing is scheduling four recordings at once, and watching them
grow, or not. This time while waiting I went to another desktop and opened
a browser, and a shortcut to a website. I received a message saying "site
cannot be reached, your network connection has been interrupted" then the
site loaded and the recordings failed. I have the HDHRs connected to a
gigabit switch > gigabit router. The successful test yesterday, found the
wife sitting at the table not the PC.

>
> Also, what do you mean by "backend is up before the HDHRs are capable
> of responding"? Since you are using network tuners, you should have
> the fix installed that causes mythbackend to wait until the HDHR
> tuners are available before it starts. But if you did not have that
> fix, the HDHRs would often not work at all after the box is booted,
> until you restarted mythbackend. But that is not the problem you seem
> to be describing.
>

At this point in time I have three internal cards (single tuners) and the
two HDHRs, normally the three are enough, but I've been tinkering with the
two for those rare times when I would need four physical tuners, so as yet
I haven't done the network ping, or backend sleep fix, primarily because
the box is on 24/7. It reboots fine, and after satisfying an upgrade with
the HDHRs first in line to record they failed, I assume because they were
not recognised at boot or reboot, as the case was. Exactly as you just
pointed out.

>
> As for the problem with shutting down the motherboard, if it shuts
> down in Windows, then it is clearly able to be made to shut down
> properly, once you find out what in Ubuntu is causing it not to shut
> down. That can be quite difficult, but it is possible. I have had
> problems like that, and what I found was the best way to diagnose
> shutdown problems was to do this:
>
> sudo systemctl enable debug-shell.service
>
> which enables a root debug console on Ctrl-Alt-F9 that comes up very
> early during boot and goes away very late during shutdown. It does
> not require a login (as it comes up before logging in is possible) and
> hence is a serious security problem when enabled, but it is able to be
> used to tell you what is happening when Ubuntu fails to shut down or
> shuts down very slowly. Once you have a debug console, then you can
> try shutting down. When the shutdown is happening, use Ctrl-Alt-F9 to
> go to the debug console and use commands like:
>
> systemctl list-jobs
>
> to see what is still running, what is waiting to be run and so on. You
> will normally find one or more jobs that are waiting a long time for
> something to happen, such as a network connection to shut down or a
> non-existent (network or local) drive to be mounted so that it can be
> unmounted.
>
> One thing that catches most MythTV users is the problem that
> mythbackend has a shut down bug itself, and fails to shut down
> completely when asked to by systemd. Systemd then does a long timeout
> before finally killing mythbackend using a kill -9 call. I think that
> takes 60 or 90 seconds, and it delays other things from getting shut
> down also. What happens in mythbackend is that most of it is shut
> down, but at least one thread fails to stop. If it is given a second
> normal shutdown request shortly after the first one, it will shut down
> immediately then. The fix I have for this problem is to put this line
> in the [service] section of your systemd override file for
> mythtv-backend:
>
> ExecStop=/usr/local/bin/mythbackendstop.sh
>
> and put a copy of my mythbackendstop.sh file in your /usr/local/bin
> directory:
>
> #!/bin/bash
> PID=$(systemctl show -p MainPID mythtv-backend.service 2>/dev/null |
> cut -d= -f2)
> if [ "$PID" != "0" ]; then
> kill -15 $PID
> sleep 1
> kill -15 $PID
> fi
>
>
> which you can do by downloading it from my web server:
>
> sudo su
> cd /usr/local/bin
> wget http://www.jsw.gen.nz/mythtv/mythbackendstop.sh
> chown root:root mythbackendstop.sh
> chmod u=rwx,g=rx,o=rx mythbackendstop.sh
> exit
>
> It is also a good idea to put these two lines in the [service] section
> as well, as a backup in case mythbackend is locked up and really needs
> a kill -9:
>
> SendSIGKILL=yes
> TimeoutStopSec=10
>
> That will do a kill -9 after 10 seconds if mythbackend still does not
> shut down.
>
> My override file for mythbackend is:
>
> /etc/systemd/system/mythtv-backend.service.d/mythtv-backend-override.conf
>
> but yours (if it exists) may have a different name. The name does not
> matter as long as it is a .conf file. The easy way to create or edit
> one these days (as long as your systemd has been updated) is:
>
> sudo systemctl edit mythtv-backend
>

Thanks Stephen, the detail you go into here for me is greatly appreciated,
and needed. Quick Q though, will the above fix interfere with ACPI? I would
think a kill would cancel the set-wakeup, I hope I'm wrong.
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, 7 Dec 2019 09:45:00 -0500, you wrote:

>On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <stephen_agent@jsw.gen.nz>
>wrote:
>
>> On Fri, 6 Dec 2019 14:00:00 -0500, you wrote:
>>
>> >Greetings Mythizens, Because my system does not shut down gracefully
>> >(Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
>> >leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and
>> >still have unreliable recording performance from them. One box failed on
>> >both recordings about ten minutes in, and then the other after 15 minutes,
>> >so I gave the first unit higher priority in my router as well as a fixed
>> >IP, and tested again with similar results. Then after some googling I
>> tried
>> >powering them down for about 15 mins, then testing again, with success.
>> Can
>> >Mythtv reboot these devices prior to putting them to use? I used to wake
>> >the box as needed, but since the mobo doesn't cooperate and the backend is
>> >up before the HDHRs are capable of responding... well you see my
>> situation,
>> >any suggestions? TIA Daryl
>>
>> I am not sure rebooting the HDHRs will help. You shut them down,
>> rather than rebooting. So it could be a temperature problem, and they
>> cooled down enough while they were off to be able to complete a
>> recording once they were restarted. So you need to test whether a
>> reboot is all that is required, or whether they actually need to be
>> shut down for a while. And you could try just pointing a fan at them
>> to see if that helps.
>>
>
>I'm not so sure either now, another test points to network traffic, what
>I've been doing is scheduling four recordings at once, and watching them
>grow, or not. This time while waiting I went to another desktop and opened
>a browser, and a shortcut to a website. I received a message saying "site
>cannot be reached, your network connection has been interrupted" then the
>site loaded and the recordings failed. I have the HDHRs connected to a
>gigabit switch > gigabit router. The successful test yesterday, found the
>wife sitting at the table not the PC.

One of the complications of using network tuners is that the traffic
from them can be swamped by other use of the same network port. A
gigabit Ethernet port is easily capable of handling the traffic from
four HD recordings, but not if you are copying a big file from a fast
hard drive or SSD to another similarly fast drive over the same
Ethernet port. The latest generations of hard drives and all SSDs are
now faster than a 1 gigabit Ethernet connection. So it is better to
run network tuners on their own network, if possible. So that would
need another switch to put the tuners on and another Ethernet card in
the MythTV backend box. But if you want other things on the network
to also be able to use the network tuners, isolating them on their own
network defeats that.

It would be really nice if the HDHRs tagged their packets with
real-time priority in the IP packet DSCP header bits. Then you could
set up the Ethernet port so that the packets with high priority took
precedence over the standard priority packets and the HDHR traffic
would be able to get through even when the port was being used to full
capacity by other traffic. Not having an HDHR, I am unable to take a
look at its packets to see what the DSCP bits are set to. There are
some posts out on the net that suggest that the DSCP bits are set, so
if they are, it would be worthwhile taking a look at what it takes to
enable QoS processing on your Ethernet port - and on your Ethernet
switch also if it supports that. But before that, someone with an
HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
recording packets and confirm the DSCP bits are being set properly.

>>
>> Also, what do you mean by "backend is up before the HDHRs are capable
>> of responding"? Since you are using network tuners, you should have
>> the fix installed that causes mythbackend to wait until the HDHR
>> tuners are available before it starts. But if you did not have that
>> fix, the HDHRs would often not work at all after the box is booted,
>> until you restarted mythbackend. But that is not the problem you seem
>> to be describing.
>>
>
>At this point in time I have three internal cards (single tuners) and the
>two HDHRs, normally the three are enough, but I've been tinkering with the
>two for those rare times when I would need four physical tuners, so as yet
>I haven't done the network ping, or backend sleep fix, primarily because
>the box is on 24/7. It reboots fine, and after satisfying an upgrade with
>the HDHRs first in line to record they failed, I assume because they were
>not recognised at boot or reboot, as the case was. Exactly as you just
>pointed out.

It would probably be better to do the startup fix, as you can get
situations such as where there has been a power failure and the box
reboots while you are not there. So after that, the HDHRs would not
work until you manually restarted mythbackend. That would be a real
pain if you were away on holiday!

>>
>> As for the problem with shutting down the motherboard, if it shuts
>> down in Windows, then it is clearly able to be made to shut down
>> properly, once you find out what in Ubuntu is causing it not to shut
>> down. That can be quite difficult, but it is possible. I have had
>> problems like that, and what I found was the best way to diagnose
>> shutdown problems was to do this:
>>
>> sudo systemctl enable debug-shell.service
>>
>> which enables a root debug console on Ctrl-Alt-F9 that comes up very
>> early during boot and goes away very late during shutdown. It does
>> not require a login (as it comes up before logging in is possible) and
>> hence is a serious security problem when enabled, but it is able to be
>> used to tell you what is happening when Ubuntu fails to shut down or
>> shuts down very slowly. Once you have a debug console, then you can
>> try shutting down. When the shutdown is happening, use Ctrl-Alt-F9 to
>> go to the debug console and use commands like:
>>
>> systemctl list-jobs
>>
>> to see what is still running, what is waiting to be run and so on. You
>> will normally find one or more jobs that are waiting a long time for
>> something to happen, such as a network connection to shut down or a
>> non-existent (network or local) drive to be mounted so that it can be
>> unmounted.
>>
>> One thing that catches most MythTV users is the problem that
>> mythbackend has a shut down bug itself, and fails to shut down
>> completely when asked to by systemd. Systemd then does a long timeout
>> before finally killing mythbackend using a kill -9 call. I think that
>> takes 60 or 90 seconds, and it delays other things from getting shut
>> down also. What happens in mythbackend is that most of it is shut
>> down, but at least one thread fails to stop. If it is given a second
>> normal shutdown request shortly after the first one, it will shut down
>> immediately then. The fix I have for this problem is to put this line
>> in the [service] section of your systemd override file for
>> mythtv-backend:
>>
>> ExecStop=/usr/local/bin/mythbackendstop.sh
>>
>> and put a copy of my mythbackendstop.sh file in your /usr/local/bin
>> directory:
>>
>> #!/bin/bash
>> PID=$(systemctl show -p MainPID mythtv-backend.service 2>/dev/null |
>> cut -d= -f2)
>> if [ "$PID" != "0" ]; then
>> kill -15 $PID
>> sleep 1
>> kill -15 $PID
>> fi
>>
>>
>> which you can do by downloading it from my web server:
>>
>> sudo su
>> cd /usr/local/bin
>> wget http://www.jsw.gen.nz/mythtv/mythbackendstop.sh
>> chown root:root mythbackendstop.sh
>> chmod u=rwx,g=rx,o=rx mythbackendstop.sh
>> exit
>>
>> It is also a good idea to put these two lines in the [service] section
>> as well, as a backup in case mythbackend is locked up and really needs
>> a kill -9:
>>
>> SendSIGKILL=yes
>> TimeoutStopSec=10
>>
>> That will do a kill -9 after 10 seconds if mythbackend still does not
>> shut down.
>>
>> My override file for mythbackend is:
>>
>> /etc/systemd/system/mythtv-backend.service.d/mythtv-backend-override.conf
>>
>> but yours (if it exists) may have a different name. The name does not
>> matter as long as it is a .conf file. The easy way to create or edit
>> one these days (as long as your systemd has been updated) is:
>>
>> sudo systemctl edit mythtv-backend
>>
>
>Thanks Stephen, the detail you go into here for me is greatly appreciated,
>and needed. Quick Q though, will the above fix interfere with ACPI? I would
>think a kill would cancel the set-wakeup, I hope I'm wrong.

I have never used the MythTV ability to shut down between recordings,
so I have no practical experience to go on. However, I can see no
reason for the ACPI setup being affected by this fix with mythbackend
as it will have done all the ACPI setup before it issues the command
to shut down which in turn will cause systemd to do the shut down.

What you do need to know is how to make systemd know that the shut
down is to be followed by an automated wake up. I have never looked
at how systemd handles that so I have no idea if you have to tell it
that a wakeup is scheduled or if you just need to have issued the
right ACPI calls beforehand. It is possible that if systemd does not
know about the scheduled wakeup, it may kill the wakeup as part of its
normal shutdown procedure.

Also, the method of shutting down the system from MythTV as installed
no longer works since systemd, as mythbackend does not have the
correct privileges to do systemctl commands such as shutdown -
attempts by mythbackend to run a shutdown command will fail. So you
need to work around that. I have done it using an sudoers helper
file, and that works well. See this post for how to set it up:

https://lists.gt.net/mythtv/users/625993

Since I have not used the ACPI shutdown ability of MythTV, I have not
tested the sudoers helper script with mythbackend, but it works well
from mythfrontend and I see no reason for mythbackend to have a
problem with it.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDHR prob with new wallwarts [ In reply to ]
I have no idea if this will be helpful but I had several issues getting my
HDHR tuners to work. I provide these in case they might be useful.

Myth address is 192.168.1.111 and is static. I set it as reserved on the
router. I also set the HDHR addresses as reserved.

I start the tuners from rc.local. Old school but works.
Here is the code. I believe this was from the vendors website.
hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
If you need to allow more time to go by, you can add a delay before this
command.

I had a power supply issue as well. The module that I bought with the HDHR
did not put out enough current so I got ones rated for more current.

I also had random failures. The computer would lose contact with the
turners every few weeks. I traced it to a linux problem as the tuners were
still visible from a Windows computer on the same network. That
troubleshooting tip was provided by Silicon Dust.

Here is the solution.

dad@NewMyth:~$ more /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet static
address 192.168.1.111
netmask 255.255.255.0
gateway 192.168.1.1
broadcast 192.168.1.255
dns-nameservers 8.8.8.8 8.8.4.4

Hope this helps.

Allen
Re: HDHR prob with new wallwarts [ In reply to ]
On 07/12/2019 17:35, Allen Edwards wrote:
> Here is the solution.
>
> dad@NewMyth:~$ more /etc/network/interfaces
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> auto enp2s0
> iface enp2s0 inet static
>     address 192.168.1.111
>     netmask 255.255.255.0
>     gateway 192.168.1.1
>     broadcast 192.168.1.255
>     dns-nameservers 8.8.8.8   8.8.4.4

Trying to decode this. I assume that the reason SD made this suggestion,
and that you report it worked for you, is that the creation of an enp2s0
entry in /etc/network/interfaces caused your backend's enp2s0 interface
no longer to be managed by the scourge that is Network Manager (scourge
on servers, not on clients).

So that should be the advice given to others: create an appropriate
entry for your backend's main ethernet interface in its
/etc/network/interfaces file. The above is just an example of what such
an entry might look like. Don't just copy it onto your backend and
assume it will work as-is; you will need to adapt it to your network and
interface name.

(Also, I would steer clear of Google's DNS servers because I value my
privacy, but that's just me).
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 07/12/2019 17:35, Allen Edwards wrote:
> > Here is the solution.
> >
> > dad@NewMyth:~$ more /etc/network/interfaces
> > # interfaces(5) file used by ifup(8) and ifdown(8)
> > auto lo
> > iface lo inet loopback
> > auto enp2s0
> > iface enp2s0 inet static
> > address 192.168.1.111
> > netmask 255.255.255.0
> > gateway 192.168.1.1
> > broadcast 192.168.1.255
> > dns-nameservers 8.8.8.8 8.8.4.4
>
> Trying to decode this. I assume that the reason SD made this suggestion,
> and that you report it worked for you, is that the creation of an enp2s0
> entry in /etc/network/interfaces caused your backend's enp2s0 interface
> no longer to be managed by the scourge that is Network Manager (scourge
> on servers, not on clients).
>
> So that should be the advice given to others: create an appropriate
> entry for your backend's main ethernet interface in its
> /etc/network/interfaces file. The above is just an example of what such
> an entry might look like. Don't just copy it onto your backend and
> assume it will work as-is; you will need to adapt it to your network and
> interface name.
>
> (Also, I would steer clear of Google's DNS servers because I value my
> privacy, but that's just me).
>
> I honestly do not recall who gave me the suggestions but I think it was on
this group but it could have been through Googling or a mixture. You are
right that it needs to be customized. This is just what I did. It kept the
HDHR connected where previously Linux was disconnecting. The HDHRs were
working fine and I could view them from Windows when the Linux box and thus
Myth could not. What SD did was suggest I use Windows to see if the HDHRs
were still connected and working at a time when Linux could not see them.
It was a great troubleshooting technique as it isolated the problem to
Linux. Not Myth, not the HDHRs.

My son works at Google and I trust them. Let me simplify the privacy issues
and what I understand Google does and does not do.
Google is in the business of selling ads and wants them to be relevant to
the viewer. There are three ways this can be done:
1) By where you are. This is similar to a newspaper having different
editions for different geographies.
2) By what you do. You visited Homedepot.com looked at lawn mowers so here
is a lawn mower ad.
3) By who you are. You are Frank and you like sex, drugs, and rock-n-roll.

Google does 1 and 2 but not 3. In California, starting next year, you can
opt out of #2. I have opted out of #2 on behalf of all my users on my
website for example so I don't need to ask everyone individually. Nice
feature. I think the EU is similar.

It is my belief that Facebook uses #3 and I do not put Google and Facebook
in the same box.

Allen
Re: HDHR prob with new wallwarts [ In reply to ]
I really appreciate all the replies and debate, but what I'd rather do,
since I use one combined FE/BE with no other FE's is swap my HDHRs for a
couple single tuner cards, preferably PCIe, I have two open slots, find
them simpler to use, and they suit my use case well, I'm using a Hauppauge
1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
you're interested.

On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
> wrote:
>
>> On 07/12/2019 17:35, Allen Edwards wrote:
>> > Here is the solution.
>> >
>> > dad@NewMyth:~$ more /etc/network/interfaces
>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>> > auto lo
>> > iface lo inet loopback
>> > auto enp2s0
>> > iface enp2s0 inet static
>> > address 192.168.1.111
>> > netmask 255.255.255.0
>> > gateway 192.168.1.1
>> > broadcast 192.168.1.255
>> > dns-nameservers 8.8.8.8 8.8.4.4
>>
>> Trying to decode this. I assume that the reason SD made this suggestion,
>> and that you report it worked for you, is that the creation of an enp2s0
>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>> no longer to be managed by the scourge that is Network Manager (scourge
>> on servers, not on clients).
>>
>> So that should be the advice given to others: create an appropriate
>> entry for your backend's main ethernet interface in its
>> /etc/network/interfaces file. The above is just an example of what such
>> an entry might look like. Don't just copy it onto your backend and
>> assume it will work as-is; you will need to adapt it to your network and
>> interface name.
>>
>> (Also, I would steer clear of Google's DNS servers because I value my
>> privacy, but that's just me).
>>
>> I honestly do not recall who gave me the suggestions but I think it was
> on this group but it could have been through Googling or a mixture. You are
> right that it needs to be customized. This is just what I did. It kept the
> HDHR connected where previously Linux was disconnecting. The HDHRs were
> working fine and I could view them from Windows when the Linux box and thus
> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
> were still connected and working at a time when Linux could not see them.
> It was a great troubleshooting technique as it isolated the problem to
> Linux. Not Myth, not the HDHRs.
>
> My son works at Google and I trust them. Let me simplify the privacy
> issues and what I understand Google does and does not do.
> Google is in the business of selling ads and wants them to be relevant to
> the viewer. There are three ways this can be done:
> 1) By where you are. This is similar to a newspaper having different
> editions for different geographies.
> 2) By what you do. You visited Homedepot.com looked at lawn mowers so here
> is a lawn mower ad.
> 3) By who you are. You are Frank and you like sex, drugs, and rock-n-roll.
>
> Google does 1 and 2 but not 3. In California, starting next year, you can
> opt out of #2. I have opted out of #2 on behalf of all my users on my
> website for example so I don't need to ask everyone individually. Nice
> feature. I think the EU is similar.
>
> It is my belief that Facebook uses #3 and I do not put Google and Facebook
> in the same box.
>
> Allen
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 10:53 AM Daryl McDonald <darylangela@gmail.com>
wrote:

> I really appreciate all the replies and debate, but what I'd rather do,
> since I use one combined FE/BE with no other FE's is swap my HDHRs for a
> couple single tuner cards, preferably PCIe, I have two open slots, find
> them simpler to use, and they suit my use case well, I'm using a Hauppauge
> 1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
> you're interested.
>
> On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
>> wrote:
>>
>>> On 07/12/2019 17:35, Allen Edwards wrote:
>>> > Here is the solution.
>>> >
>>> > dad@NewMyth:~$ more /etc/network/interfaces
>>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>>> > auto lo
>>> > iface lo inet loopback
>>> > auto enp2s0
>>> > iface enp2s0 inet static
>>> > address 192.168.1.111
>>> > netmask 255.255.255.0
>>> > gateway 192.168.1.1
>>> > broadcast 192.168.1.255
>>> > dns-nameservers 8.8.8.8 8.8.4.4
>>>
>>> Trying to decode this. I assume that the reason SD made this suggestion,
>>> and that you report it worked for you, is that the creation of an enp2s0
>>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>>> no longer to be managed by the scourge that is Network Manager (scourge
>>> on servers, not on clients).
>>>
>>> So that should be the advice given to others: create an appropriate
>>> entry for your backend's main ethernet interface in its
>>> /etc/network/interfaces file. The above is just an example of what such
>>> an entry might look like. Don't just copy it onto your backend and
>>> assume it will work as-is; you will need to adapt it to your network and
>>> interface name.
>>>
>>> (Also, I would steer clear of Google's DNS servers because I value my
>>> privacy, but that's just me).
>>>
>>> I honestly do not recall who gave me the suggestions but I think it was
>> on this group but it could have been through Googling or a mixture. You are
>> right that it needs to be customized. This is just what I did. It kept the
>> HDHR connected where previously Linux was disconnecting. The HDHRs were
>> working fine and I could view them from Windows when the Linux box and thus
>> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
>> were still connected and working at a time when Linux could not see them.
>> It was a great troubleshooting technique as it isolated the problem to
>> Linux. Not Myth, not the HDHRs.
>>
>> My son works at Google and I trust them. Let me simplify the privacy
>> issues and what I understand Google does and does not do.
>> Google is in the business of selling ads and wants them to be relevant to
>> the viewer. There are three ways this can be done:
>> 1) By where you are. This is similar to a newspaper having different
>> editions for different geographies.
>> 2) By what you do. You visited Homedepot.com looked at lawn mowers so
>> here is a lawn mower ad.
>> 3) By who you are. You are Frank and you like sex, drugs, and rock-n-roll.
>>
>> Google does 1 and 2 but not 3. In California, starting next year, you can
>> opt out of #2. I have opted out of #2 on behalf of all my users on my
>> website for example so I don't need to ask everyone individually. Nice
>> feature. I think the EU is similar.
>>
>> It is my belief that Facebook uses #3 and I do not put Google and
>> Facebook in the same box.
>>
>> Allen
>>
>
I went the other way. Took out my internal tuner cards and used the HDHR.
So long ago I can't remember all the reasons but I know internal heat in
the computer case was one. I liked it so much I bought a second one on
Craigslist, which is how I got the underrated wall wart that ended up
giving me problems. My tuner cards are a decade old so probably not worth
using but I can go look if you are interested.

Allen
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 10:39 AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sat, 7 Dec 2019 09:45:00 -0500, you wrote:
>
> >On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <
> stephen_agent@jsw.gen.nz>
> >wrote:
> >
> >> On Fri, 6 Dec 2019 14:00:00 -0500, you wrote:
> >>
> >> >Greetings Mythizens, Because my system does not shut down gracefully
> >> >(Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
> >> >leaving it on 24/7. I finally got new wallwarts for both of my HDHR's
> and
> >> >still have unreliable recording performance from them. One box failed
> on
> >> >both recordings about ten minutes in, and then the other after 15
> minutes,
> >> >so I gave the first unit higher priority in my router as well as a
> fixed
> >> >IP, and tested again with similar results. Then after some googling I
> >> tried
> >> >powering them down for about 15 mins, then testing again, with success.
> >> Can
> >> >Mythtv reboot these devices prior to putting them to use? I used to
> wake
> >> >the box as needed, but since the mobo doesn't cooperate and the
> backend is
> >> >up before the HDHRs are capable of responding... well you see my
> >> situation,
> >> >any suggestions? TIA Daryl
> >>
> >> I am not sure rebooting the HDHRs will help. You shut them down,
> >> rather than rebooting. So it could be a temperature problem, and they
> >> cooled down enough while they were off to be able to complete a
> >> recording once they were restarted. So you need to test whether a
> >> reboot is all that is required, or whether they actually need to be
> >> shut down for a while. And you could try just pointing a fan at them
> >> to see if that helps.
> >>
> >
> >I'm not so sure either now, another test points to network traffic, what
> >I've been doing is scheduling four recordings at once, and watching them
> >grow, or not. This time while waiting I went to another desktop and opened
> >a browser, and a shortcut to a website. I received a message saying "site
> >cannot be reached, your network connection has been interrupted" then the
> >site loaded and the recordings failed. I have the HDHRs connected to a
> >gigabit switch > gigabit router. The successful test yesterday, found the
> >wife sitting at the table not the PC.
>
> One of the complications of using network tuners is that the traffic
> from them can be swamped by other use of the same network port. A
> gigabit Ethernet port is easily capable of handling the traffic from
> four HD recordings, but not if you are copying a big file from a fast
> hard drive or SSD to another similarly fast drive over the same
> Ethernet port. The latest generations of hard drives and all SSDs are
> now faster than a 1 gigabit Ethernet connection. So it is better to
> run network tuners on their own network, if possible. So that would
> need another switch to put the tuners on and another Ethernet card in
> the MythTV backend box. But if you want other things on the network
> to also be able to use the network tuners, isolating them on their own
> network defeats that.
>

It was insomnia testing 4am I started four recordings, then opened a
browser on my FE/BE and immediately the recordings failed no other network
traffic at all.

>
> It would be really nice if the HDHRs tagged their packets with
> real-time priority in the IP packet DSCP header bits. Then you could
> set up the Ethernet port so that the packets with high priority took
> precedence over the standard priority packets and the HDHR traffic
> would be able to get through even when the port was being used to full
> capacity by other traffic. Not having an HDHR, I am unable to take a
> look at its packets to see what the DSCP bits are set to. There are
> some posts out on the net that suggest that the DSCP bits are set, so
> if they are, it would be worthwhile taking a look at what it takes to
> enable QoS processing on your Ethernet port - and on your Ethernet
> switch also if it supports that. But before that, someone with an
> HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
> recording packets and confirm the DSCP bits are being set properly.
>

My router allows 1 top priority service 2 second level priority and ten
normal priority device staging. My wife's VoIP phone takes the top spot and
the HDHRs occupy the next two spots. This change was made prior the the
last test. The ethrenet switch is a "smart switch" maybe that is where I'm
getting into trouble?

>
> >>
> >> Also, what do you mean by "backend is up before the HDHRs are capable
> >> of responding"? Since you are using network tuners, you should have
> >> the fix installed that causes mythbackend to wait until the HDHR
> >> tuners are available before it starts. But if you did not have that
> >> fix, the HDHRs would often not work at all after the box is booted,
> >> until you restarted mythbackend. But that is not the problem you seem
> >> to be describing.
> >>
> >
> >At this point in time I have three internal cards (single tuners) and the
> >two HDHRs, normally the three are enough, but I've been tinkering with the
> >two for those rare times when I would need four physical tuners, so as yet
> >I haven't done the network ping, or backend sleep fix, primarily because
> >the box is on 24/7. It reboots fine, and after satisfying an upgrade with
> >the HDHRs first in line to record they failed, I assume because they were
> >not recognised at boot or reboot, as the case was. Exactly as you just
> >pointed out.
>
> It would probably be better to do the startup fix, as you can get
> situations such as where there has been a power failure and the box
> reboots while you are not there. So after that, the HDHRs would not
> work until you manually restarted mythbackend. That would be a real
> pain if you were away on holiday!
>
> >>
> >> As for the problem with shutting down the motherboard, if it shuts
> >> down in Windows, then it is clearly able to be made to shut down
> >> properly, once you find out what in Ubuntu is causing it not to shut
> >> down. That can be quite difficult, but it is possible. I have had
> >> problems like that, and what I found was the best way to diagnose
> >> shutdown problems was to do this:
> >>
> >> sudo systemctl enable debug-shell.service
> >>
> >> which enables a root debug console on Ctrl-Alt-F9 that comes up very
> >> early during boot and goes away very late during shutdown. It does
> >> not require a login (as it comes up before logging in is possible) and
> >> hence is a serious security problem when enabled, but it is able to be
> >> used to tell you what is happening when Ubuntu fails to shut down or
> >> shuts down very slowly. Once you have a debug console, then you can
> >> try shutting down. When the shutdown is happening, use Ctrl-Alt-F9 to
> >> go to the debug console and use commands like:
> >>
> >> systemctl list-jobs
> >>
> >> to see what is still running, what is waiting to be run and so on. You
> >> will normally find one or more jobs that are waiting a long time for
> >> something to happen, such as a network connection to shut down or a
> >> non-existent (network or local) drive to be mounted so that it can be
> >> unmounted.
> >>
> >> One thing that catches most MythTV users is the problem that
> >> mythbackend has a shut down bug itself, and fails to shut down
> >> completely when asked to by systemd. Systemd then does a long timeout
> >> before finally killing mythbackend using a kill -9 call. I think that
> >> takes 60 or 90 seconds, and it delays other things from getting shut
> >> down also. What happens in mythbackend is that most of it is shut
> >> down, but at least one thread fails to stop. If it is given a second
> >> normal shutdown request shortly after the first one, it will shut down
> >> immediately then. The fix I have for this problem is to put this line
> >> in the [service] section of your systemd override file for
> >> mythtv-backend:
> >>
> >> ExecStop=/usr/local/bin/mythbackendstop.sh
> >>
> >> and put a copy of my mythbackendstop.sh file in your /usr/local/bin
> >> directory:
> >>
> >> #!/bin/bash
> >> PID=$(systemctl show -p MainPID mythtv-backend.service 2>/dev/null |
> >> cut -d= -f2)
> >> if [ "$PID" != "0" ]; then
> >> kill -15 $PID
> >> sleep 1
> >> kill -15 $PID
> >> fi
> >>
> >>
> >> which you can do by downloading it from my web server:
> >>
> >> sudo su
> >> cd /usr/local/bin
> >> wget http://www.jsw.gen.nz/mythtv/mythbackendstop.sh
> >> chown root:root mythbackendstop.sh
> >> chmod u=rwx,g=rx,o=rx mythbackendstop.sh
> >> exit
> >>
> >> It is also a good idea to put these two lines in the [service] section
> >> as well, as a backup in case mythbackend is locked up and really needs
> >> a kill -9:
> >>
> >> SendSIGKILL=yes
> >> TimeoutStopSec=10
> >>
> >> That will do a kill -9 after 10 seconds if mythbackend still does not
> >> shut down.
> >>
> >> My override file for mythbackend is:
> >>
> >>
> /etc/systemd/system/mythtv-backend.service.d/mythtv-backend-override.conf
> >>
> >> but yours (if it exists) may have a different name. The name does not
> >> matter as long as it is a .conf file. The easy way to create or edit
> >> one these days (as long as your systemd has been updated) is:
> >>
> >> sudo systemctl edit mythtv-backend
> >>
> >
> >Thanks Stephen, the detail you go into here for me is greatly appreciated,
> >and needed. Quick Q though, will the above fix interfere with ACPI? I
> would
> >think a kill would cancel the set-wakeup, I hope I'm wrong.
>
> I have never used the MythTV ability to shut down between recordings,
> so I have no practical experience to go on. However, I can see no
> reason for the ACPI setup being affected by this fix with mythbackend
> as it will have done all the ACPI setup before it issues the command
> to shut down which in turn will cause systemd to do the shut down.
>
> What you do need to know is how to make systemd know that the shut
> down is to be followed by an automated wake up. I have never looked
> at how systemd handles that so I have no idea if you have to tell it
> that a wakeup is scheduled or if you just need to have issued the
> right ACPI calls beforehand. It is possible that if systemd does not
> know about the scheduled wakeup, it may kill the wakeup as part of its
> normal shutdown procedure.
>
> Also, the method of shutting down the system from MythTV as installed
> no longer works since systemd, as mythbackend does not have the
> correct privileges to do systemctl commands such as shutdown -
> attempts by mythbackend to run a shutdown command will fail. So you
> need to work around that. I have done it using an sudoers helper
> file, and that works well. See this post for how to set it up:
>
> https://lists.gt.net/mythtv/users/625993
>
> Since I have not used the ACPI shutdown ability of MythTV, I have not
> tested the sudoers helper script with mythbackend, but it works well
> from mythfrontend and I see no reason for mythbackend to have a
> problem with it.
>

Thamks for the post, that ias acconmplished.
Re: HDHR prob with new wallwarts [ In reply to ]
yes, very interested, what do you have?

On Sat, Dec 7, 2019 at 2:27 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Sat, Dec 7, 2019 at 10:53 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>> I really appreciate all the replies and debate, but what I'd rather do,
>> since I use one combined FE/BE with no other FE's is swap my HDHRs for a
>> couple single tuner cards, preferably PCIe, I have two open slots, find
>> them simpler to use, and they suit my use case well, I'm using a Hauppauge
>> 1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
>> you're interested.
>>
>> On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
>>> wrote:
>>>
>>>> On 07/12/2019 17:35, Allen Edwards wrote:
>>>> > Here is the solution.
>>>> >
>>>> > dad@NewMyth:~$ more /etc/network/interfaces
>>>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>>>> > auto lo
>>>> > iface lo inet loopback
>>>> > auto enp2s0
>>>> > iface enp2s0 inet static
>>>> > address 192.168.1.111
>>>> > netmask 255.255.255.0
>>>> > gateway 192.168.1.1
>>>> > broadcast 192.168.1.255
>>>> > dns-nameservers 8.8.8.8 8.8.4.4
>>>>
>>>> Trying to decode this. I assume that the reason SD made this suggestion,
>>>> and that you report it worked for you, is that the creation of an enp2s0
>>>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>>>> no longer to be managed by the scourge that is Network Manager (scourge
>>>> on servers, not on clients).
>>>>
>>>> So that should be the advice given to others: create an appropriate
>>>> entry for your backend's main ethernet interface in its
>>>> /etc/network/interfaces file. The above is just an example of what such
>>>> an entry might look like. Don't just copy it onto your backend and
>>>> assume it will work as-is; you will need to adapt it to your network and
>>>> interface name.
>>>>
>>>> (Also, I would steer clear of Google's DNS servers because I value my
>>>> privacy, but that's just me).
>>>>
>>>> I honestly do not recall who gave me the suggestions but I think it was
>>> on this group but it could have been through Googling or a mixture. You are
>>> right that it needs to be customized. This is just what I did. It kept the
>>> HDHR connected where previously Linux was disconnecting. The HDHRs were
>>> working fine and I could view them from Windows when the Linux box and thus
>>> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
>>> were still connected and working at a time when Linux could not see them.
>>> It was a great troubleshooting technique as it isolated the problem to
>>> Linux. Not Myth, not the HDHRs.
>>>
>>> My son works at Google and I trust them. Let me simplify the privacy
>>> issues and what I understand Google does and does not do.
>>> Google is in the business of selling ads and wants them to be relevant
>>> to the viewer. There are three ways this can be done:
>>> 1) By where you are. This is similar to a newspaper having different
>>> editions for different geographies.
>>> 2) By what you do. You visited Homedepot.com looked at lawn mowers so
>>> here is a lawn mower ad.
>>> 3) By who you are. You are Frank and you like sex, drugs, and
>>> rock-n-roll.
>>>
>>> Google does 1 and 2 but not 3. In California, starting next year, you
>>> can opt out of #2. I have opted out of #2 on behalf of all my users on my
>>> website for example so I don't need to ask everyone individually. Nice
>>> feature. I think the EU is similar.
>>>
>>> It is my belief that Facebook uses #3 and I do not put Google and
>>> Facebook in the same box.
>>>
>>> Allen
>>>
>>
> I went the other way. Took out my internal tuner cards and used the HDHR.
> So long ago I can't remember all the reasons but I know internal heat in
> the computer case was one. I liked it so much I bought a second one on
> Craigslist, which is how I got the underrated wall wart that ended up
> giving me problems. My tuner cards are a decade old so probably not worth
> using but I can go look if you are interested.
>
> Allen
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Fri, 6 Dec 2019 14:00:00 -0500, you wrote:
>
> >Greetings Mythizens, Because my system does not shut down gracefully
> >(Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
> >leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and
> >still have unreliable recording performance from them. One box failed on
> >both recordings about ten minutes in, and then the other after 15 minutes,
> >so I gave the first unit higher priority in my router as well as a fixed
> >IP, and tested again with similar results. Then after some googling I
> tried
> >powering them down for about 15 mins, then testing again, with success.
> Can
> >Mythtv reboot these devices prior to putting them to use? I used to wake
> >the box as needed, but since the mobo doesn't cooperate and the backend is
> >up before the HDHRs are capable of responding... well you see my
> situation,
> >any suggestions? TIA Daryl
>
> I am not sure rebooting the HDHRs will help. You shut them down,
> rather than rebooting. So it could be a temperature problem, and they
> cooled down enough while they were off to be able to complete a
> recording once they were restarted. So you need to test whether a
> reboot is all that is required, or whether they actually need to be
> shut down for a while. And you could try just pointing a fan at them
> to see if that helps.
>
> Also, what do you mean by "backend is up before the HDHRs are capable
> of responding"? Since you are using network tuners, you should have
> the fix installed that causes mythbackend to wait until the HDHR
> tuners are available before it starts. But if you did not have that
> fix, the HDHRs would often not work at all after the box is booted,
> until you restarted mythbackend. But that is not the problem you seem
> to be describing.
>
> As for the problem with shutting down the motherboard, if it shuts
> down in Windows, then it is clearly able to be made to shut down
> properly, once you find out what in Ubuntu is causing it not to shut
> down. That can be quite difficult, but it is possible. I have had
> problems like that, and what I found was the best way to diagnose
> shutdown problems was to do this:
>
> sudo systemctl enable debug-shell.service
>
> which enables a root debug console on Ctrl-Alt-F9 that comes up very
> early during boot and goes away very late during shutdown. It does
> not require a login (as it comes up before logging in is possible) and
> hence is a serious security problem when enabled, but it is able to be
> used to tell you what is happening when Ubuntu fails to shut down or
> shuts down very slowly. Once you have a debug console, then you can
> try shutting down. When the shutdown is happening, use Ctrl-Alt-F9 to
> go to the debug console and use commands like:
>

So before I enable the debug-shell.service is disabling it as easy as:

sudo systemctl disable debug-shell.service ? If I hear you correctly, I
don't want to leave myself open any longer than necessary (the debug
process) ?

>
> systemctl list-jobs
>
> to see what is still running, what is waiting to be run and so on. You
> will normally find one or more jobs that are waiting a long time for
> something to happen, such as a network connection to shut down or a
> non-existent (network or local) drive to be mounted so that it can be
> unmounted.
>
> One thing that catches most MythTV users is the problem that
> mythbackend has a shut down bug itself, and fails to shut down
> completely when asked to by systemd. Systemd then does a long timeout
> before finally killing mythbackend using a kill -9 call. I think that
> takes 60 or 90 seconds, and it delays other things from getting shut
> down also. What happens in mythbackend is that most of it is shut
> down, but at least one thread fails to stop. If it is given a second
> normal shutdown request shortly after the first one, it will shut down
> immediately then. The fix I have for this problem is to put this line
> in the [service] section of your systemd override file for
> mythtv-backend:
>
> ExecStop=/usr/local/bin/mythbackendstop.sh
>
> and put a copy of my mythbackendstop.sh file in your /usr/local/bin
> directory:
>
> #!/bin/bash
> PID=$(systemctl show -p MainPID mythtv-backend.service 2>/dev/null |
> cut -d= -f2)
> if [ "$PID" != "0" ]; then
> kill -15 $PID
> sleep 1
> kill -15 $PID
> fi
>
>
> which you can do by downloading it from my web server:
>
> sudo su
> cd /usr/local/bin
> wget http://www.jsw.gen.nz/mythtv/mythbackendstop.sh
> chown root:root mythbackendstop.sh
> chmod u=rwx,g=rx,o=rx mythbackendstop.sh
> exit
>
> It is also a good idea to put these two lines in the [service] section
> as well, as a backup in case mythbackend is locked up and really needs
> a kill -9:
>
> SendSIGKILL=yes
> TimeoutStopSec=10
>
> That will do a kill -9 after 10 seconds if mythbackend still does not
> shut down.
>
> My override file for mythbackend is:
>
> /etc/systemd/system/mythtv-backend.service.d/mythtv-backend-override.conf
>
> but yours (if it exists) may have a different name. The name does not
> matter as long as it is a .conf file. The easy way to create or edit
> one these days (as long as your systemd has been updated) is:
>
> sudo systemctl edit mythtv-backend
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: HDHR prob with new wallwarts [ In reply to ]
One after thought Allen, I can't use an analog tuner it myust be digital,
thanks

On Sat, Dec 7, 2019 at 2:29 PM Daryl McDonald <darylangela@gmail.com> wrote:

> yes, very interested, what do you have?
>
> On Sat, Dec 7, 2019 at 2:27 PM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Dec 7, 2019 at 10:53 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>> I really appreciate all the replies and debate, but what I'd rather do,
>>> since I use one combined FE/BE with no other FE's is swap my HDHRs for a
>>> couple single tuner cards, preferably PCIe, I have two open slots, find
>>> them simpler to use, and they suit my use case well, I'm using a Hauppauge
>>> 1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
>>> you're interested.
>>>
>>> On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
>>>> wrote:
>>>>
>>>>> On 07/12/2019 17:35, Allen Edwards wrote:
>>>>> > Here is the solution.
>>>>> >
>>>>> > dad@NewMyth:~$ more /etc/network/interfaces
>>>>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>>>>> > auto lo
>>>>> > iface lo inet loopback
>>>>> > auto enp2s0
>>>>> > iface enp2s0 inet static
>>>>> > address 192.168.1.111
>>>>> > netmask 255.255.255.0
>>>>> > gateway 192.168.1.1
>>>>> > broadcast 192.168.1.255
>>>>> > dns-nameservers 8.8.8.8 8.8.4.4
>>>>>
>>>>> Trying to decode this. I assume that the reason SD made this
>>>>> suggestion,
>>>>> and that you report it worked for you, is that the creation of an
>>>>> enp2s0
>>>>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>>>>> no longer to be managed by the scourge that is Network Manager (scourge
>>>>> on servers, not on clients).
>>>>>
>>>>> So that should be the advice given to others: create an appropriate
>>>>> entry for your backend's main ethernet interface in its
>>>>> /etc/network/interfaces file. The above is just an example of what such
>>>>> an entry might look like. Don't just copy it onto your backend and
>>>>> assume it will work as-is; you will need to adapt it to your network
>>>>> and
>>>>> interface name.
>>>>>
>>>>> (Also, I would steer clear of Google's DNS servers because I value my
>>>>> privacy, but that's just me).
>>>>>
>>>>> I honestly do not recall who gave me the suggestions but I think it
>>>> was on this group but it could have been through Googling or a mixture. You
>>>> are right that it needs to be customized. This is just what I did. It kept
>>>> the HDHR connected where previously Linux was disconnecting. The HDHRs were
>>>> working fine and I could view them from Windows when the Linux box and thus
>>>> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
>>>> were still connected and working at a time when Linux could not see them.
>>>> It was a great troubleshooting technique as it isolated the problem to
>>>> Linux. Not Myth, not the HDHRs.
>>>>
>>>> My son works at Google and I trust them. Let me simplify the privacy
>>>> issues and what I understand Google does and does not do.
>>>> Google is in the business of selling ads and wants them to be relevant
>>>> to the viewer. There are three ways this can be done:
>>>> 1) By where you are. This is similar to a newspaper having different
>>>> editions for different geographies.
>>>> 2) By what you do. You visited Homedepot.com looked at lawn mowers so
>>>> here is a lawn mower ad.
>>>> 3) By who you are. You are Frank and you like sex, drugs, and
>>>> rock-n-roll.
>>>>
>>>> Google does 1 and 2 but not 3. In California, starting next year, you
>>>> can opt out of #2. I have opted out of #2 on behalf of all my users on my
>>>> website for example so I don't need to ask everyone individually. Nice
>>>> feature. I think the EU is similar.
>>>>
>>>> It is my belief that Facebook uses #3 and I do not put Google and
>>>> Facebook in the same box.
>>>>
>>>> Allen
>>>>
>>>
>> I went the other way. Took out my internal tuner cards and used the
>> HDHR. So long ago I can't remember all the reasons but I know internal
>> heat in the computer case was one. I liked it so much I bought a second one
>> on Craigslist, which is how I got the underrated wall wart that ended up
>> giving me problems. My tuner cards are a decade old so probably not worth
>> using but I can go look if you are interested.
>>
>> Allen
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 11:57 AM Daryl McDonald <darylangela@gmail.com>
wrote:

> One after thought Allen, I can't use an analog tuner it myust be digital,
> thanks
> mythtv.org <https://forum.mythtv.org>


https://linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-PCI rev 1.

I guess the reason for my post was to talk you out of using cards like I
did. I would bet that newer cards are much better as this card is old but
the HDHR units work flawlessly once you set them up. Of course, I also use
the optical feature for my remote. That may have been a factor in my
switch. I have two HDHR original dual boxes. No complaints.

Allen
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 3:59 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Sat, Dec 7, 2019 at 11:57 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>> One after thought Allen, I can't use an analog tuner it myust be digital,
>> thanks
>> mythtv.org <https://forum.mythtv.org>
>
>
> https://linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-PCI rev 1.
>
> I guess the reason for my post was to talk you out of using cards like I
> did. I would bet that newer cards are much better as this card is old but
> the HDHR units work flawlessly once you set them up. Of course, I also use
> the optical feature for my remote. That may have been a factor in my
> switch. I have two HDHR original dual boxes. No complaints.
>
> Allen
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org



https://www.amazon.ca/Ziyituod-Network-Ethernet-Gigabit-1000Mbps/dp/B07T55GSF9/ref=sr_1_4?keywords=NIC&qid=1575756626&sr=8-4&th=1

Would one of these network cards allow me to connect both HDHRs directly to
the PC and avouid network traffic issues?
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019, 10:40 AM Stephen Worthington, <stephen_agent@jsw.gen.nz>
wrote:




It would be really nice if the HDHRs tagged their packets with
real-time priority in the IP packet DSCP header bits. Then you could
set up the Ethernet port so that the packets with high priority took
precedence over the standard priority packets and the HDHR traffic
would be able to get through even when the port was being used to full
capacity by other traffic. Not having an HDHR, I am unable to take a
look at its packets to see what the DSCP bits are set to. There are
some posts out on the net that suggest that the DSCP bits are set, so
if they are, it would be worthwhile taking a look at what it takes to
enable QoS processing on your Ethernet port - and on your Ethernet
switch also if it supports that. But before that, someone with an
HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
recording packets and confirm the DSCP bits are being set properly.


Don't know if this is helpful or outdated but did a search on HDHomerun and
DSCP and this came up:

http://mythtvblog.blogspot.com/2008/03/enabling-quality-of-service-for.html?m=1
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, 7 Dec 2019 18:21:44 -0500, you wrote:

>On Sat, Dec 7, 2019, 10:40 AM Stephen Worthington, <stephen_agent@jsw.gen.nz>
>wrote:
>
>
>
>
>It would be really nice if the HDHRs tagged their packets with
>real-time priority in the IP packet DSCP header bits. Then you could
>set up the Ethernet port so that the packets with high priority took
>precedence over the standard priority packets and the HDHR traffic
>would be able to get through even when the port was being used to full
>capacity by other traffic. Not having an HDHR, I am unable to take a
>look at its packets to see what the DSCP bits are set to. There are
>some posts out on the net that suggest that the DSCP bits are set, so
>if they are, it would be worthwhile taking a look at what it takes to
>enable QoS processing on your Ethernet port - and on your Ethernet
>switch also if it supports that. But before that, someone with an
>HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
>recording packets and confirm the DSCP bits are being set properly.
>
>
>Don't know if this is helpful or outdated but did a search on HDHomerun and
>DSCP and this came up:
>
>http://mythtvblog.blogspot.com/2008/03/enabling-quality-of-service-for.html?m=1

Using that method of doing QoS looks like it would work, but is pretty
painful as it requires a patch to MythTV and using VLANs. I would
hope that by now the HDHR firmware would support using the DSCP bit in
the IP headers, and do it as a default (not needing to be enabled in
the URL that starts a recording). That would make it much easier to
use.

So is there anyone who is using an HDHR with the latest firmware who
would be able to do a capture of the packets and take a look at the
DSCP bits? Or post a capture file somewhere for me to download?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, 7 Dec 2019 14:47:30 -0500, you wrote:

>So before I enable the debug-shell.service is disabling it as easy as:
>
>sudo systemctl disable debug-shell.service ? If I hear you correctly, I
>don't want to leave myself open any longer than necessary (the debug
>process) ?

Yes, that is the way to do it. You do need to reboot afterwards for
that command to take effect. I have never tried this, but it should
shut down the debug shell immediately if you do this:

sudo systemctl stop debug-shell.service

which would avoid the need for a reboot. Test to make sure it worked
by doing Ctrl-Alt-F9. There should no longer be any response from the
shell that was running there. You would still need to do the
systemctl disable command or the debug shell would be back at the next
reboot.

If you have never used things like Ctrl-Alt-F9 before, you need to
remember that Ctrl-Alt-F7 will get you back to the GUI screen. During
shut down, the GUI goes away fairly early, so when trying to debug
shutdown problems, if Ctrl-Alt-F7 does not work, that is not a problem
as all it means is the GUI got shut down normally. Just do
Ctrl-Alt-F9 to get back to the debug shell again.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDHR prob with new wallwarts [ In reply to ]
>It would be really nice if the HDHRs tagged their packets with

> >real-time priority in the IP packet DSCP header bits. Then you could
> >set up the Ethernet port so that the packets with high priority took
> >precedence over the standard priority packets and the HDHR traffic
> >would be able to get through even when the port was being used to full
> >capacity by other traffic. Not having an HDHR, I am unable to take a
> >look at its packets to see what the DSCP bits are set to. There are
> >some posts out on the net that suggest that the DSCP bits are set, so
> >if they are, it would be worthwhile taking a look at what it takes to
> >enable QoS processing on your Ethernet port - and on your Ethernet
> >switch also if it supports that. But before that, someone with an
> >HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
> >recording packets and confirm the DSCP bits are being set properly.
>
> Hi,

Nick here from SIlicondust...

All HDHomeRun models tag UDP and RTP video stream packets with IP_TOS =
(5<<5). No target option required.

After reviewing I see two possible quirks...
1) Wireshark is reporting that as CS5 whereas I think it should be CS3 for
broadcast video.
2) The HDHomeRun should probably tag HTTP video stream packets with CS3 as
well.

Nick
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 7:56 PM Silicondust <mythtv@silicondust.com> wrote:

> >It would be really nice if the HDHRs tagged their packets with
>
>> >real-time priority in the IP packet DSCP header bits. Then you could
>> >set up the Ethernet port so that the packets with high priority took
>> >precedence over the standard priority packets and the HDHR traffic
>> >would be able to get through even when the port was being used to full
>> >capacity by other traffic. Not having an HDHR, I am unable to take a
>> >look at its packets to see what the DSCP bits are set to. There are
>> >some posts out on the net that suggest that the DSCP bits are set, so
>> >if they are, it would be worthwhile taking a look at what it takes to
>> >enable QoS processing on your Ethernet port - and on your Ethernet
>> >switch also if it supports that. But before that, someone with an
>> >HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
>> >recording packets and confirm the DSCP bits are being set properly.
>>
>> All HDHomeRun models tag UDP and RTP video stream packets with IP_TOS =
> (5<<5). No target option required.
>
> After reviewing I see two possible quirks...
> 1) Wireshark is reporting that as CS5 whereas I think it should be CS3 for
> broadcast video.
> 2) The HDHomeRun should probably tag HTTP video stream packets with CS3 as
> well.
>
> Correction - all HDHomeRun models tag UDP, RTP, and HTTP video stream
packets with CS5 today.
The only question is if it should be CS3 rather than CS5.
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, 7 Dec 2019 14:28:42 -0500, you wrote:

>It was insomnia testing 4am I started four recordings, then opened a
>browser on my FE/BE and immediately the recordings failed no other network
>traffic at all.

So that makes it unlikely that it was a traffic problem that caused
the bad recordings.

When you say "failed", what exactly happened? Did the recordings just
stop, or did they complete but had lots of errors?

>My router allows 1 top priority service 2 second level priority and ten
>normal priority device staging. My wife's VoIP phone takes the top spot and
>the HDHRs occupy the next two spots. This change was made prior the the
>last test. The ethrenet switch is a "smart switch" maybe that is where I'm
>getting into trouble?

I am presuming that you have your MythTV box and HDHRs all connected
to the same "smart switch" and on the same subnet. If so, then the
packets between the HDHRs and the MythTV box will never be going to
the router, and will not be affected by its QoS operations. The
packets will be switched by the Ethernet switch between its ports
without ever getting to the router.

Ideally, you would want your switch to do DSCP QoS, but it is unlikely
it is capable of that. QoS in switches is usually only found in
enterprise grade switches or top end consumer ones. But you certainly
should look up your switch to see if it is capable of doing DSCP QoS.

I have an EdgeSwitch ES-24-LITE:

https://www.ui.com/edgemax/edgeswitch-lite/

which is an enterprise grade switch and has full QoS capabilities.
That is one of the features I bought it for. I have it configured to
do DSCP priority on all ports, but I have never actually tested to see
if it is working as I do not have any problems that would actually
need DSCP to be working.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDHR prob with new wallwarts [ In reply to ]
On Sat, Dec 7, 2019 at 8:17 PM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Sat, 7 Dec 2019 14:28:42 -0500, you wrote:
>
> >It was insomnia testing 4am I started four recordings, then opened a
> >browser on my FE/BE and immediately the recordings failed no other network
> >traffic at all.
>
> So that makes it unlikely that it was a traffic problem that caused
> the bad recordings.
>
> When you say "failed", what exactly happened? Did the recordings just
> stop, or did they complete but had lots of errors?
>
> >My router allows 1 top priority service 2 second level priority and ten
> >normal priority device staging. My wife's VoIP phone takes the top spot
> and
> >the HDHRs occupy the next two spots. This change was made prior the the
> >last test. The ethrenet switch is a "smart switch" maybe that is where I'm
> >getting into trouble?
>
> I am presuming that you have your MythTV box and HDHRs all connected
> to the same "smart switch" and on the same subnet. If so, then the
> packets between the HDHRs and the MythTV box will never be going to
> the router, and will not be affected by its QoS operations. The
> packets will be switched by the Ethernet switch between its ports
> without ever getting to the router.
>
> Ideally, you would want your switch to do DSCP QoS, but it is unlikely
> it is capable of that. QoS in switches is usually only found in
> enterprise grade switches or top end consumer ones. But you certainly
> should look up your switch to see if it is capable of doing DSCP QoS.
>
> I have an EdgeSwitch ES-24-LITE:
>
> https://www.ui.com/edgemax/edgeswitch-lite/
>
> which is an enterprise grade switch and has full QoS capabilities.
> That is one of the features I bought it for. I have it configured to
> do DSCP priority on all ports, but I have never actually tested to see
> if it is working as I do not have any problems that would actually
> need DSCP to be working.
> _______________________________________________
>
>
I use a Cisco-Linksys EZXS55W EtherFast 10/100 5-Port Workgroup Switch.
It has two HDHR and the Myth computer into it as well as the line going to
my R6700 Nighthawk router.
No problems whatsoever since I made the changes to the Linux configuration.

Allen

1 2 3  View All