[mythtv-users] mythtv-users Digest, Vol 206, Issue 19

jam@tigger.ws jameslinder0 at gmail.com
Tue May 12 07:18:46 UTC 2020


Send mythtv-users mailing list submissions to
	mythtv-users at mythtv.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.mythtv.org/mailman/listinfo/mythtv-users
or, via email, send a message with subject or body 'help' to
	mythtv-users-request at mythtv.org

You can reach the person managing the list at
	mythtv-users-owner at mythtv.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mythtv-users digest..."


Today's Topics:

  1. Re: scan again (faginbagin)
  2. Re: licrd not working in Xubuntu 20.04 (James Abernathy)
  3. Re: licrd not working in Xubuntu 20.04 (Stephen Worthington)
  4. Re: HDPVR intermittent failure (DryHeat122 .)
  5. Re: licrd not working in Xubuntu 20.04 (James Abernathy)
  6. Re: Raspberry Pi 4 FrontEnd Remote Control Issues (Barry Martin)
  7. Re: licrd not working in Xubuntu 20.04 (James Abernathy)
  8. Re: scan again (Blue)
  9. Re: MAC (John Hoyt)
 10. Re: MAC (John Hoyt)
 11. Re: MAC (Dave Pearson (Lists))


----------------------------------------------------------------------

Message: 1
Date: Mon, 11 May 2020 14:45:39 -0400
From: faginbagin <mythtv at hbuus.com>
To: mythtv-users at mythtv.org
Subject: Re: [mythtv-users] scan again
Message-ID: <edf78fba-e721-b0c2-1ef4-b240d23b0b13 at hbuus.com>
Content-Type: text/plain; charset=utf-8

On 5/11/2020 4:57 AM, Blue wrote:
> Hi All
> I?m playing with a xubuntu test install of 31. (built from src)
> for the first part I just copied some movies into /store/Movies
> I scanned and played.
> I then mv?d them to /store/Movies/Myth-A
> I scanned again
> 
> frontend shows all the movies in base directory
> I can play the movies, even though they are not there
> No folder ?Myth-A? has been scanned
> 
> This is *not* the behaviour I expect, have come to appreciate or understand
> I can find no mention of this, what is happening
> 
> Thanks
> James
> 

After the second scan, did you leave the "Watch Videos" screen and go into something else like "Watch Recordings" and then go back to "Watch Videos"? I have found that if you leave "Watch Videos" to its parent menu "Media Library" and then go back to "Watch Videos" it does not show changes that should be seen as a result of a scan, maybe because it doesn't do garbage collection (just a guess). At least that's my observation with v29. Also, how do you scan? Using the "Watch Videos" menu, or the command:
"mythutil --scanvideos"?
I use the second method. And if I don't leave, go somewhere else that's not just a menu, and then go back, the frontend is prone to crashing. Again using v29.


------------------------------

Message: 2
Date: Mon, 11 May 2020 15:07:17 -0400
From: James Abernathy <jfabernathy at gmail.com>
To: Stephen Worthington <stephen at jsw.gen.nz>, Discussion about MythTV
	<mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] licrd not working in Xubuntu 20.04
Message-ID:
	<CANFv2EkdudrX5txXhFXCua-5uhgWpSg_UEKtnChudk89zqyQqQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, May 11, 2020 at 2:44 PM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> On Mon, 11 May 2020 14:36:19 -0400, you wrote:
> 
>> On Mon, May 11, 2020 at 12:32 PM Stephen Worthington <
>> stephen_agent at jsw.gen.nz> wrote:
>> 
>>> 
>>> 
>>> Only having the arrow keys working is the normal symptom of lirc not
>>> working at all and mythfrontend getting keystrokes directly from the
>>> devinput driver.  The arrow keys are normally the only ones that are
>>> mapped to something that mythfrontend responds to.  Maybe the number
>>> keys will also work.  I would suggest trying the irw program to see if
>>> there is any output from the lirc socket when you press a remote
>>> button.  I am guessing that there will be nothing.
>>> 
>>> I ran irw and then pressed a number of buttons on the remote and got
> this
>> output:
>> 
>> 0000000080010160 00 KEY_OK devinput-32
>> 00000000800100cf 00 KEY_PLAY devinput-32
>> 00000000800100cf 00 KEY_PLAY devinput-32
>> 0000000080010160 00 KEY_OK devinput-32
>> 0000000080010080 00 KEY_STOP devinput-32
>> 0000000080010077 00 KEY_PAUSE devinput-32
>> 0000000080010197 00 KEY_NEXT devinput-32
>> 000000008001019c 00 KEY_PREVIOUS devinput-32
>> 00000000800100ae 00 KEY_EXIT devinput-32
>> 000000008001006a 00 KEY_RIGHT devinput-32
>> 0000000080010067 00 KEY_UP devinput-32
>> 0000000080010069 00 KEY_LEFT devinput-32
>> 000000008001006c 00 KEY_DOWN devinput-32
>> 0000000080010160 00 KEY_OK devinput-32
>> 0000000080010201 00 KEY_NUMERIC_1 devinput-32
>> 0000000080010202 00 KEY_NUMERIC_2 devinput-32
>> 0000000080010203 00 KEY_NUMERIC_3 devinput-32
>> 0000000080010204 00 KEY_NUMERIC_4 devinput-32
>> 0000000080010205 00 KEY_NUMERIC_5 devinput-32
>> 0000000080010206 00 KEY_NUMERIC_6 devinput-32
>> 0000000080010207 00 KEY_NUMERIC_7 devinput-32
>> 0000000080010208 00 KEY_NUMERIC_8 devinput-32
>> 0000000080010209 00 KEY_NUMERIC_9 devinput-32
>> 000000008001020a 00 KEY_NUMERIC_STAR devinput-32
>> 000000008001020b 00 KEY_NUMERIC_POUND devinput-32
> 
> OK, your remote is using the name devinput-32 instead of devinput or
> devinput-64.  Just a name change required to match the name in your
> $HOME/.lirc/* files.  That is easier than changing the names in all
> the entries in the $HOME/.lirc/* files.  They are probably using the
> name devinput.  And your numeric keys are using KEY_NUMERIC_* instead
> of the KEY_* used in the $HOME/.lirc/*.  There are a few other key
> names that will also not match.  See the modified rc6_mce file in the
> download from my server.
> 

maybe getting closer. in /etc/lirc/lircd.conf.d/devinput.lircd.conf I
changed:
      name            devinput-64
to
   name               devinput-32

However I do not have a $HOME/.lirc/ directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200511/36b24995/attachment-0001.htm>

------------------------------

Message: 3
Date: Tue, 12 May 2020 07:22:20 +1200
From: Stephen Worthington <stephen_agent at jsw.gen.nz>
To: Discussion about MythTV <mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] licrd not working in Xubuntu 20.04
Message-ID: <dt8jbf9u0f90a1vfljo3vbm6n5iv6sno8b at 4ax.com>
Content-Type: text/plain; charset=us-ascii

On Mon, 11 May 2020 15:07:17 -0400, you wrote:

> On Mon, May 11, 2020 at 2:44 PM Stephen Worthington <
> stephen_agent at jsw.gen.nz> wrote:
> 
>> On Mon, 11 May 2020 14:36:19 -0400, you wrote:
>> 
>>> On Mon, May 11, 2020 at 12:32 PM Stephen Worthington <
>>> stephen_agent at jsw.gen.nz> wrote:
>>> 
>>>> 
>>>> 
>>>> Only having the arrow keys working is the normal symptom of lirc not
>>>> working at all and mythfrontend getting keystrokes directly from the
>>>> devinput driver.  The arrow keys are normally the only ones that are
>>>> mapped to something that mythfrontend responds to.  Maybe the number
>>>> keys will also work.  I would suggest trying the irw program to see if
>>>> there is any output from the lirc socket when you press a remote
>>>> button.  I am guessing that there will be nothing.
>>>> 
>>>> I ran irw and then pressed a number of buttons on the remote and got
>> this
>>> output:
>>> 
>>> 0000000080010160 00 KEY_OK devinput-32
>>> 00000000800100cf 00 KEY_PLAY devinput-32
>>> 00000000800100cf 00 KEY_PLAY devinput-32
>>> 0000000080010160 00 KEY_OK devinput-32
>>> 0000000080010080 00 KEY_STOP devinput-32
>>> 0000000080010077 00 KEY_PAUSE devinput-32
>>> 0000000080010197 00 KEY_NEXT devinput-32
>>> 000000008001019c 00 KEY_PREVIOUS devinput-32
>>> 00000000800100ae 00 KEY_EXIT devinput-32
>>> 000000008001006a 00 KEY_RIGHT devinput-32
>>> 0000000080010067 00 KEY_UP devinput-32
>>> 0000000080010069 00 KEY_LEFT devinput-32
>>> 000000008001006c 00 KEY_DOWN devinput-32
>>> 0000000080010160 00 KEY_OK devinput-32
>>> 0000000080010201 00 KEY_NUMERIC_1 devinput-32
>>> 0000000080010202 00 KEY_NUMERIC_2 devinput-32
>>> 0000000080010203 00 KEY_NUMERIC_3 devinput-32
>>> 0000000080010204 00 KEY_NUMERIC_4 devinput-32
>>> 0000000080010205 00 KEY_NUMERIC_5 devinput-32
>>> 0000000080010206 00 KEY_NUMERIC_6 devinput-32
>>> 0000000080010207 00 KEY_NUMERIC_7 devinput-32
>>> 0000000080010208 00 KEY_NUMERIC_8 devinput-32
>>> 0000000080010209 00 KEY_NUMERIC_9 devinput-32
>>> 000000008001020a 00 KEY_NUMERIC_STAR devinput-32
>>> 000000008001020b 00 KEY_NUMERIC_POUND devinput-32
>> 
>> OK, your remote is using the name devinput-32 instead of devinput or
>> devinput-64.  Just a name change required to match the name in your
>> $HOME/.lirc/* files.  That is easier than changing the names in all
>> the entries in the $HOME/.lirc/* files.  They are probably using the
>> name devinput.  And your numeric keys are using KEY_NUMERIC_* instead
>> of the KEY_* used in the $HOME/.lirc/*.  There are a few other key
>> names that will also not match.  See the modified rc6_mce file in the
>> download from my server.
>> 
> 
> maybe getting closer. in /etc/lirc/lircd.conf.d/devinput.lircd.conf I
> changed:
>      name            devinput-64
> to
>   name               devinput-32

Not quite right, I think.  There should be two tables in your
devinput.lircd.conf file, named devinput-64 and devinput-32.  Your
keycodes are matching the devinput-32 table, so that is the one you
want to rename to devinput.  The table name is used for output to the
lirc socket that irw and MythTV connects to, not for input matching.
The matching of the input in lircd is according to the protocol
setting lines also at the top of each table.

> However I do not have a $HOME/.lirc/ directory.

Download the file in my other post.  The files are in there.  They use
the name devinput for their input matching of data received from the
lirc socket.

See /etc/lirc/lirc_options.conf for the name of the lirc socket
("output =").


------------------------------

Message: 4
Date: Mon, 11 May 2020 12:59:37 -0700
From: "DryHeat122 ." <dryheat122 at gmail.com>
To: Discussion about MythTV <mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] HDPVR intermittent failure
Message-ID:
	<CAM=qwAHd73cNqhnvCvKsPZyooMTZH1kwuZRytSyO3vfeRL0zww at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
> 
>> On Sun, May 10, 2020, 7:58 PM Greg <gregl at nycap.rr.com> wrote:
> 
>> Ok thanks I will investigate that.  But it's been working fine with the
>> current power source for like a year now, and others on this list use it
>> too.
> 
> USB cables often fit badly into the sockets.  If so, the connection
> generally gets worse over time as you get dirt or oxidisation on the
> contacts.  So badly fitting cables will degrade with time.  The result
> is that the voltage drop across the cable will increase markedly.  And
> they can be too thin - the amount of copper in the wires is too little
> and that causes high resistance and a big voltage drop across the
> length of the cable.  Some (most?) USB cables are designed only for
> data transmission, or to run very low power devices.  For a high power
> device, you need a better (thicker) cable.  The high power devices do
> a negotiation with device supplying the power and request high power
> mode.  If the cable is not capable of high power, that negotiation is
> not supposed to work and the device should either only work in low
> power mode or it should turn itself off.  But USB cable makers often
> make cables not capable of high power transmission that will allow the
> high power mode negotiation to succeed.  So even though the device
> supplying the power is sending high current, the voltage drop in the
> cable means that at the other end, the voltage can be below the level
> required for proper operation or to fully charge the device's battery.
> 
> I have had two notably bad experiences with USB cables.  One was a USB
> DVB-T tuner, and it was very like your experience - it would go for a
> number of days just fine, then suddenly stop.  If I unplugged it and
> plugged it in again, it would usually work again.  When I finally
> investigated properly, I found the cable was just a little loose in
> the PC's socket.  I replaced the cable with one that fit more tightly
> and the tuner was much more reliable.  It still occasionally caused
> trouble, but only when I had bumped the cables (or in one case, after
> we had a small earthquake).  So because of that and because I needed
> more DVB-T tuners, I finally replaced all my DVB-T tuners with an 8
> tuner PCIe card.
> 
> The second bad experience was my Samsung Galaxy Tab S2 tablet.  Its
> USB charging cable was supplied with it by Samsung, so I assumed it
> was a good one.  But right from the start, the tablet took a long time
> to charge, and the time gradually got longer and longer and the
> battery life on one charge was getting less and less.  And then I
> started to have to jiggle the cable in the socket to get it to charge
> at all.  I actually called the Samsung help line about this, and they
> said it sounds like a bad cable.  So I bought a expensive (NZ$30)
> Pudney & Lee charging cable, which was a fair bit longer than the old
> Samsung cable, but fit very tightly at both ends and was significantly
> thicker - it has more copper in the wires in the cable.  Then suddenly
> the battery charging times were what was specified for the tablet,
> rather than three times as long.  And over a number of charging
> cycles, the battery life came back again.  So the original Samsung
> supplied cable was clearly bad from the start - it is probably less
> than the specification required to charge the tablet properly as it is
> too thin and has too much voltage drop even when the plugs fit
> properly.  So definitely NZ$30 well spent.  But I am surprised that a
> reputable company like Samsung would supply a bad cable with an
> expensive top-of-the-line product like my tablet.  But they did - so
> now I always suspect any USB cable I get and keep an eye on how well
> it is working.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


Thanks for all the suggestions.  I will investigate all of them.  Something
I do not see in here is an opinion that some software problem could have
evolved.  I was kind of thinking of that as a possibility given that it
worked fine for so long then seems to be degrading.  OTOH I never thought
of the possibility that the USB connection could be degrading.  I'm going
to try Greg's connector, assuming I can get parts during the Apocalypse.
Also, his link specifies Radio Shack parts.  What's Radio Shack?!? ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200511/26957405/attachment-0001.htm>

------------------------------

Message: 5
Date: Mon, 11 May 2020 16:00:11 -0400
From: James Abernathy <jfabernathy at gmail.com>
To: Stephen Worthington <stephen at jsw.gen.nz>, Discussion about MythTV
	<mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] licrd not working in Xubuntu 20.04
Message-ID:
	<CANFv2E=Hfk_0D_ya1a1pOF_-5idR80KupgXXGv5WNBpO8axf2g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, May 11, 2020 at 3:24 PM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> On Mon, 11 May 2020 15:07:17 -0400, you wrote:
> 
>> On Mon, May 11, 2020 at 2:44 PM Stephen Worthington <
>> stephen_agent at jsw.gen.nz> wrote:
>> 
>>> On Mon, 11 May 2020 14:36:19 -0400, you wrote:
>>> 
>>>> On Mon, May 11, 2020 at 12:32 PM Stephen Worthington <
>>>> stephen_agent at jsw.gen.nz> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> Only having the arrow keys working is the normal symptom of lirc not
>>>>> working at all and mythfrontend getting keystrokes directly from the
>>>>> devinput driver.  The arrow keys are normally the only ones that are
>>>>> mapped to something that mythfrontend responds to.  Maybe the number
>>>>> keys will also work.  I would suggest trying the irw program to see
> if
>>>>> there is any output from the lirc socket when you press a remote
>>>>> button.  I am guessing that there will be nothing.
>>>>> 
>>>>> I ran irw and then pressed a number of buttons on the remote and got
>>> this
>>>> output:
>>>> 
>>>> 0000000080010160 00 KEY_OK devinput-32
>>>> 00000000800100cf 00 KEY_PLAY devinput-32
>>>> 00000000800100cf 00 KEY_PLAY devinput-32
>>>> 0000000080010160 00 KEY_OK devinput-32
>>>> 0000000080010080 00 KEY_STOP devinput-32
>>>> 0000000080010077 00 KEY_PAUSE devinput-32
>>>> 0000000080010197 00 KEY_NEXT devinput-32
>>>> 000000008001019c 00 KEY_PREVIOUS devinput-32
>>>> 00000000800100ae 00 KEY_EXIT devinput-32
>>>> 000000008001006a 00 KEY_RIGHT devinput-32
>>>> 0000000080010067 00 KEY_UP devinput-32
>>>> 0000000080010069 00 KEY_LEFT devinput-32
>>>> 000000008001006c 00 KEY_DOWN devinput-32
>>>> 0000000080010160 00 KEY_OK devinput-32
>>>> 0000000080010201 00 KEY_NUMERIC_1 devinput-32
>>>> 0000000080010202 00 KEY_NUMERIC_2 devinput-32
>>>> 0000000080010203 00 KEY_NUMERIC_3 devinput-32
>>>> 0000000080010204 00 KEY_NUMERIC_4 devinput-32
>>>> 0000000080010205 00 KEY_NUMERIC_5 devinput-32
>>>> 0000000080010206 00 KEY_NUMERIC_6 devinput-32
>>>> 0000000080010207 00 KEY_NUMERIC_7 devinput-32
>>>> 0000000080010208 00 KEY_NUMERIC_8 devinput-32
>>>> 0000000080010209 00 KEY_NUMERIC_9 devinput-32
>>>> 000000008001020a 00 KEY_NUMERIC_STAR devinput-32
>>>> 000000008001020b 00 KEY_NUMERIC_POUND devinput-32
>>> 
>>> OK, your remote is using the name devinput-32 instead of devinput or
>>> devinput-64.  Just a name change required to match the name in your
>>> $HOME/.lirc/* files.  That is easier than changing the names in all
>>> the entries in the $HOME/.lirc/* files.  They are probably using the
>>> name devinput.  And your numeric keys are using KEY_NUMERIC_* instead
>>> of the KEY_* used in the $HOME/.lirc/*.  There are a few other key
>>> names that will also not match.  See the modified rc6_mce file in the
>>> download from my server.
>>> 
>> 
>> maybe getting closer. in /etc/lirc/lircd.conf.d/devinput.lircd.conf I
>> changed:
>>      name            devinput-64
>> to
>>   name               devinput-32
> 
> Not quite right, I think.  There should be two tables in your
> devinput.lircd.conf file, named devinput-64 and devinput-32.  Your
> keycodes are matching the devinput-32 table, so that is the one you
> want to rename to devinput.  The table name is used for output to the
> lirc socket that irw and MythTV connects to, not for input matching.
> The matching of the input in lircd is according to the protocol
> setting lines also at the top of each table.
> 
>> However I do not have a $HOME/.lirc/ directory.
> 
> Download the file in my other post.  The files are in there.  They use
> the name devinput for their input matching of data received from the
> lirc socket.
> 
> See /etc/lirc/lirc_options.conf for the name of the lirc socket
> ("output =").
> 

Sorry for the confusion on my part. back on mythbuntu 14 and 16 I had to do
none of this get my MCE remote working.

So I have the 2 tables in devinput.lirc.conf
name               devinput-64   and
name               devinput-32 which is now renames to
name               devinput
The files I downloaded from your server had a number of lines proceeding
each section with a lot of garbage like:
-^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

Are the files still good?
Jim A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200511/8b7540c0/attachment-0001.htm>

------------------------------

Message: 6
Date: Mon, 11 May 2020 16:09:10 -0500
From: Barry Martin <barry3martin at gmail.com>
To: mythtv-users at mythtv.org
Subject: Re: [mythtv-users] Raspberry Pi 4 FrontEnd Remote Control
	Issues
Message-ID: <2549c7f5-f377-47ac-0228-f7996b90e1e1 at GMail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"


Hi Stephen!


> The Seiki configuration file - - the one I found at
> https://gist.github.com/gisikw/a2ffa7f45efa0d9c3bee ? is at
> /etc/lirc/lircd.conf.d/Seiki_LIRC.conf . Good news is it is found/listed
> by **systemctl status lircd.socket lircd.service**.
> Good, that is the right place for it.

Figured it was in the correct subdir, just nice to have verified and 
that being in the wrong place wasn?t the problem.



> What is the output of:   sudo ir-keytable
> (without the -t).  It should list your IR receiver(s).

pi at RPi-MythFE:~ $ sudo ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event4) with:
	Name: gpio_ir_recv
	Driver: gpio_ir_recv, table: rc-rc6-mce
	LIRC device: /dev/lirc0
	Attached BPF protocols: Operation not supported
	Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon
	Enabled kernel protocols: lirc
	bus: 25, vendor/product: 0001:0001, version: 0x0100
	Repeat delay = 500 ms, repeat period = 125 ms
pi at RPi-MythFE:~ $



> I do not know how your remote works, just that it clearly does.  IR
> remotes need IR receiver hardware, which can be included in or with
> tuners or as a separate device.  The actual receiver is typically an
> IR photo-diode, and in less naked devices than an RPi it is usually
> hidden behind a small hole or transparent plastic window.  So when you
> are using your remote, what are you pointing it at?  Does the RPi4
> have a builtin IR receiver, or have you added one?
I added the IR detector from a Hauppage tuner. According to on-line 
information for an after-market replacement uses a TSOP 2238 IR 
Receiver. Information from PiHut says they sell the TSOP3802. AFAICT 
equivalent for my usage. (PiHut seemed to indicate an IR detector was 
fine, just the pinouts could differ.)


As for directing the remote control?s head, yes, directly to the opening 
in the Hauppauge sensor ? it?s hard to miss! <g> When nothing is 
indicated on the screen the remote is closer and with grit ? you know 
that joke about how one presses the buttons harder on a remote control 
with dead batteries?! Yup! <g>



You had a question on the version: /sudo lircd -v /


pi at RPi-MythFE:~ $ sudo lircd -v

lircd 0.10.1



Thanks!

Barry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200511/eff0ec6a/attachment-0001.htm>

------------------------------

Message: 7
Date: Mon, 11 May 2020 18:06:51 -0400
From: James Abernathy <jfabernathy at gmail.com>
To: Stephen Worthington <stephen at jsw.gen.nz>, Discussion about MythTV
	<mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] licrd not working in Xubuntu 20.04
Message-ID:
	<CANFv2EnCm15L4DUsSh8mvGwaO0JyzZ0f+ZMr1vP3pfc1HB_RYA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, May 11, 2020 at 4:00 PM James Abernathy <jfabernathy at gmail.com>
wrote:

> 
> 
> On Mon, May 11, 2020 at 3:24 PM Stephen Worthington <
> stephen_agent at jsw.gen.nz> wrote:
> 
>> On Mon, 11 May 2020 15:07:17 -0400, you wrote:
>> 
>>> On Mon, May 11, 2020 at 2:44 PM Stephen Worthington <
>>> stephen_agent at jsw.gen.nz> wrote:
>>> 
>>>> On Mon, 11 May 2020 14:36:19 -0400, you wrote:
>>>> 
>>>>> On Mon, May 11, 2020 at 12:32 PM Stephen Worthington <
>>>>> stephen_agent at jsw.gen.nz> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Only having the arrow keys working is the normal symptom of lirc not
>>>>>> working at all and mythfrontend getting keystrokes directly from the
>>>>>> devinput driver.  The arrow keys are normally the only ones that are
>>>>>> mapped to something that mythfrontend responds to.  Maybe the number
>>>>>> keys will also work.  I would suggest trying the irw program to see
>> if
>>>>>> there is any output from the lirc socket when you press a remote
>>>>>> button.  I am guessing that there will be nothing.
>>>>>> 
>>>>>> I ran irw and then pressed a number of buttons on the remote and got
>>>> this
>>>>> output:
>>>>> 
>>>>> 0000000080010160 00 KEY_OK devinput-32
>>>>> 00000000800100cf 00 KEY_PLAY devinput-32
>>>>> 00000000800100cf 00 KEY_PLAY devinput-32
>>>>> 0000000080010160 00 KEY_OK devinput-32
>>>>> 0000000080010080 00 KEY_STOP devinput-32
>>>>> 0000000080010077 00 KEY_PAUSE devinput-32
>>>>> 0000000080010197 00 KEY_NEXT devinput-32
>>>>> 000000008001019c 00 KEY_PREVIOUS devinput-32
>>>>> 00000000800100ae 00 KEY_EXIT devinput-32
>>>>> 000000008001006a 00 KEY_RIGHT devinput-32
>>>>> 0000000080010067 00 KEY_UP devinput-32
>>>>> 0000000080010069 00 KEY_LEFT devinput-32
>>>>> 000000008001006c 00 KEY_DOWN devinput-32
>>>>> 0000000080010160 00 KEY_OK devinput-32
>>>>> 0000000080010201 00 KEY_NUMERIC_1 devinput-32
>>>>> 0000000080010202 00 KEY_NUMERIC_2 devinput-32
>>>>> 0000000080010203 00 KEY_NUMERIC_3 devinput-32
>>>>> 0000000080010204 00 KEY_NUMERIC_4 devinput-32
>>>>> 0000000080010205 00 KEY_NUMERIC_5 devinput-32
>>>>> 0000000080010206 00 KEY_NUMERIC_6 devinput-32
>>>>> 0000000080010207 00 KEY_NUMERIC_7 devinput-32
>>>>> 0000000080010208 00 KEY_NUMERIC_8 devinput-32
>>>>> 0000000080010209 00 KEY_NUMERIC_9 devinput-32
>>>>> 000000008001020a 00 KEY_NUMERIC_STAR devinput-32
>>>>> 000000008001020b 00 KEY_NUMERIC_POUND devinput-32
>>>> 
>>>> OK, your remote is using the name devinput-32 instead of devinput or
>>>> devinput-64.  Just a name change required to match the name in your
>>>> $HOME/.lirc/* files.  That is easier than changing the names in all
>>>> the entries in the $HOME/.lirc/* files.  They are probably using the
>>>> name devinput.  And your numeric keys are using KEY_NUMERIC_* instead
>>>> of the KEY_* used in the $HOME/.lirc/*.  There are a few other key
>>>> names that will also not match.  See the modified rc6_mce file in the
>>>> download from my server.
>>>> 
>>> 
>>> maybe getting closer. in /etc/lirc/lircd.conf.d/devinput.lircd.conf I
>>> changed:
>>>      name            devinput-64
>>> to
>>>   name               devinput-32
>> 
>> Not quite right, I think.  There should be two tables in your
>> devinput.lircd.conf file, named devinput-64 and devinput-32.  Your
>> keycodes are matching the devinput-32 table, so that is the one you
>> want to rename to devinput.  The table name is used for output to the
>> lirc socket that irw and MythTV connects to, not for input matching.
>> The matching of the input in lircd is according to the protocol
>> setting lines also at the top of each table.
>> 
>>> However I do not have a $HOME/.lirc/ directory.
>> 
>> Download the file in my other post.  The files are in there.  They use
>> the name devinput for their input matching of data received from the
>> lirc socket.
>> 
>> See /etc/lirc/lirc_options.conf for the name of the lirc socket
>> ("output =").
>> 
> 
> Sorry for the confusion on my part. back on mythbuntu 14 and 16 I had to
> do none of this get my MCE remote working.
> 
> So I have the 2 tables in devinput.lirc.conf
> name               devinput-64   and
> name               devinput-32 which is now renames to
> name               devinput
> The files I downloaded from your server had a number of lines proceeding
> each section with a lot of garbage like:
> -^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
> 
> Are the files still good?
> Jim A
> 

I should just say "never mind" :-)
I found  what is called an Air Mouse remote (
https://www.mythtv.org/wiki/Air_mouse_rf_remote) I had bought ($15) for
another application on a Raspberry Pi.  I decided to try that on Mythtv
Frontend on the Ubuntu PC. I should have started with that.
I just plugged in the receiver and it worked as described on the mythtv
wiki page. so far I have only used "Edit Keys" Function to redefine the
Home key to Escape.

I like being able to have a Qwerty keyboard on the other side of the remote.

For now, I'll just throw the MCE remote and receiver back in the attic.

Thanks for your help as always.

Jim A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200511/d1fd3017/attachment-0001.htm>

------------------------------

Message: 8
Date: Tue, 12 May 2020 08:45:44 +0800
From: Blue <jam at tigger.ws>
To: mythtv-users at mythtv.org
Subject: Re: [mythtv-users] scan again
Message-ID: <6BDAD435-A697-4D54-AC45-BBF792E5B01B at tigger.ws>
Content-Type: text/plain;	charset=utf-8



> On 11 May 2020, at 6:49 pm, mythtv-users-request at mythtv.org wrote:
> 
>>> Hi All
>>> I?m playing with a xubuntu test install of 31. (built from src)
>>> for the first part I just copied some movies into /store/Movies
>>> I scanned and played.
>>> I then mv?d them to /store/Movies/Myth-A
>>> I scanned again
>>> 
>>> frontend shows all the movies in base directory
>>> I can play the movies, even though they are not there
>>> No folder ?Myth-A? has been scanned
>>> 
>>> This is *not* the behaviour I expect, have come to appreciate or understand
>>> I can find no mention of this, what is happening
>> 
>> Are you using storage groups for the videos?  If so, then it does not
>> matter where in the storage groups a video file is, as long as it has
>> the same file name. 
> 
> I think Stephen is right that it's SG related; but, for the record, for 
> Videos the matching is surely on the file hash (which is a little fuzzy, 
> but that's not the issue here) ?
> 
> So if you have multiple directory paths in a
>> storage group and move files between them, MythTV is not bothered and
>> will find the files.  This is the same way the storage groups for
>> recordings work.  The actual path to the files is not stored anywhere
>> in the database, and mythbackend will search the entire storage group
>> to find a specific file.
>> 
>> There are also different ways of displaying the video files - it
>> sounds like you are not using the one that displays the tree of where
>> they are.
>> 
>> I am still using v30, so it is also possible that there have been some
>> changes in v31.

I copied the next folder, Myth-B, there, scanned and everything is correct.
I?m much more comfortable, but I?m sure I uncovered a bug, just rare and not easily reproduced, so I?ll ignore it.
James

------------------------------

Message: 9
Date: Mon, 11 May 2020 21:21:36 -0400
From: John Hoyt <john.hoyt at gmail.com>
To: Discussion about MythTV <mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] MAC
Message-ID:
	<CAE8sghRQLPg3cjgXBjeh2V=9x+Gr1Z+oSn_eM4Z-jW+fFgmg5Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

It looks like I missed the "--runprefix=../Resources" when calling
configure. Also makebundle did not copy the themes and i18n folders into
the app.  I'm compiling now and hoping to post a new .dmg file up to
dropbox tomorrow morning.

> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200511/cbb72611/attachment-0001.htm>

------------------------------

Message: 10
Date: Mon, 11 May 2020 21:43:33 -0400
From: John Hoyt <john.hoyt at gmail.com>
To: Discussion about MythTV <mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] MAC
Message-ID:
	<CAE8sghTV==zQ+zsErpk6-iG-yErvpVBRUJtkzNoqj1CTXK-tJw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I take it back, the compile completed before I gave up for the evening.

Please try the file at this link:
https://www.dropbox.com/s/xarebulww4pgg9h/mythfrontend-31.dmg?dl=0

> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200511/6c8aebfb/attachment-0001.htm>

------------------------------

Message: 11
Date: Tue, 12 May 2020 05:28:20 +0000
From: Dave Pearson (Lists) <lists at the-pearsons.co.uk>
To: Discussion about MythTV <mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] MAC
Message-ID: <kcis.152931EBF2514BDFAEE04FB7EA87920B at 06dcc9f8072d>
Content-Type: text/plain; charset="utf-8"

-----Original message-----
From: John Hoyt?<john.hoyt at gmail.com>
Sent: Tuesday 12th May 2020 2:44
To: Discussion about MythTV <mythtv-users at mythtv.org>
Subject: Re: [mythtv-users] MAC

I take it back, the compile completed before I gave up for the evening.

Please try the file at this link:?https://www.dropbox.com/s/xarebulww4pgg9h/mythfrontend-31.dmg?dl=0
Hi John,



That's fixed the menus, now all I need to do is figure out the right playback profile settings so that the video displays in full screen on my MacBook Pro Retina, rather than just taking up the bottom left quarter.



Regards,

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200512/1fee96eb/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
mythtv-users mailing list
mythtv-users at mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org


------------------------------

End of mythtv-users Digest, Vol 206, Issue 19
*********************************************


More information about the mythtv-users mailing list