Re: [RDD] Troubleshooting setup of PyPAD

[Alejandro Olivan Alvarez]

Hi Fred.

Thank you for your help!

As an early note... just to point out that PyPad IS ACTUALLY working 
FLAWLESSLY  :-)  to the extend of my very little initial experiments 
(artist - title to Icecast2) once I overcome the mentioned issues:


Here the problem was: I'm a noob ... and I missed to enable the required 
feature (I don't remember the name) on the Groups... once I enabled 
that, boom! It worked!


Now, but, since I'm aware you're working hard on Debianizing Rivendell, 
I understand your worries.



On 7/3/21 4:01 PM, Fred Gleason wrote:
On Jul 2, 2021, at 07:54, Alejandro olivan Alvarez 
> wrote:



I'm playing with the PyPAD stuff of Rivendell.

So far, I've managed to have an script running... so far the problems 
I've had to evercome (Debian Stable Buster install) were:


- The documented (on this list) Centos/debianish misplacing of 
pypad.py which needs to be copied to /usr/lib64/rivendell/pypad


 cp /usr/lib/python3.7/site-packages/pypad.py /usr/lib64/rivendell/pypad


That doesn’t look right, on a couple of levels.

First, ‘/usr/lib64’ is a RedHat-ism. Ubuntu at least doesn’t seem to 
use that convention at all, but rather installs binary linkable 
objects under ‘/usr/lib’ regardless of the target arch. I’ve not 
actually checked on Debian, but I’d be somewhat surprised if things 
are different there as Ubuntu seems to copy Debian pretty closely in 
general file layout.


Second, while the PyPAD scripts themselves (think of them as ‘user 
programs’) do indeed need to go in ${libdir}/rivendell/pypad (which 
evaluates to ‘/usr/lib/rivendell/pypad’ on Debian-is setups), the 
PyPAD *library module* should go in the default system location so it 
will be in Python’s search path. On Ubuntu, this location is 
‘/usr/lib/python3/dist-packages’.


N.B. Python supports the concept of having multiple parallel 
installations of different versions, each of which get their own 
orthogonal module store. On my UbuntuStudio 20.04 setup, the default 
installation has installed no less than four different versions of 
Python, resulting separate module paths for each (in my case, 
‘/usr/lib/python2.7/dist-packages’, ‘/usr/lib/python3/dist-packages’, 
‘/usr/lib/python3.8/dist-packages’ and 
‘/usr/lib/python3.9/dist-packages’). These locations appear to be a 
Debian-ism inasmuch as Automake's AM_PATH_PYTHON() macro doesn’t 
recognize them, instead using the expected standard Python defaults. 
At present, there is a nasty hack in ‘configure.in’ (lines 290-305) 
that attempts to detect this situation and install things the ‘Debian 
way’ if necessary. I would love some feedback on how this works on 
various Debian-ish setups (or, even better, PRs that improve the 
heuristic).


My tests are being done on Rivendell master, using Debian packages that 
I barely build myself using debuild... So no surprise I doesn't install 
well being a RedHattish source.




I've created a copy of the included icecast2.py and also the related 
icecast2.exemplar. So far the script works, green dot and no errors. 
A ps on console shows the script running:


root@debian:~# ps aux | grep pypad
pypad 4095  3.9  0.1 285108 28624 ?    Sl   12:18   2:38 
/usr/sbin/rdpadengined
pypad 4097  4.2  0.1 211368 28412 ?    S    12:18   2:50 
/usr/sbin/rdrssd
pypad 9777  0.0  0.1  40812 23948 ?    S    12:25   0:00 
/usr/bin/python3 /usr/lib64/rivendell/pypad/pypad_icecast2_8000.py 
localhost 34289 $1

root 22462  0.0  0.0   6208 824 pts/1    S+   13:25   0:00 grep pypad

The TCP port for metadata appears listening:

root@debian:~# netstat -tnlp | grep 34289
tcp    0  0 0.0.0.0:34289 0.0.0.0:*   LISTEN  
4073/rdpadd



I've setup username/password/port/mountpoint on the configuration... 
apparently, OK... now, the problem:


I've no song update on the Icecast2 server


Ok, first thing to do is verify that your Icecast2 system will accept 
metadata updates from your PyPAD host. Icecast is famously picky in 
this regard; updates *must* originate (or appear to it to be be 
originating) from the same source IP address as the encoder client 
originating the stream; updates that fail to meet this criterion are 
ignored. A good way to test this is to attempt to send a metadata 
update *from the same system that is running the PyPAD script* 
manually via a curl(1) command of the form:


curl -u source: 
http://:/admin/metadata?mount==updinfo=


where:

- The hostname or IP address of the system running Icecast

- The TCP port number of the Icecast instance

- The mountpoint of the stream

 - The mount point password.

- The string to set, encoded as specified in Section 2 of RFC3986

For example, to set a string of "The Beatles - Hey Jude” at an Icecast 
instance running at "icecast.example.com:1234 
" with a

mountpoint of “MyStream” and a password of “hackme", the URL would be:

curl -u source:hackme 

Re: [RDD] Troubleshooting setup of PyPAD

[Fred Gleason]

On Jul 2, 2021, at 07:54, Alejandro olivan Alvarez 
 wrote:

> I'm playing with the PyPAD stuff of Rivendell.
> 
> So far, I've managed to have an script running... so far the problems I've 
> had to evercome (Debian Stable Buster install) were:
> 
> - The documented (on this list) Centos/debianish misplacing of pypad.py which 
> needs to be copied to /usr/lib64/rivendell/pypad
> 
>  cp /usr/lib/python3.7/site-packages/pypad.py /usr/lib64/rivendell/pypad

That doesn’t look right, on a couple of levels. 

First, ‘/usr/lib64’ is a RedHat-ism. Ubuntu at least doesn’t seem to use that 
convention at all, but rather installs binary linkable objects under ‘/usr/lib’ 
regardless of the target arch. I’ve not actually checked on Debian, but I’d be 
somewhat surprised if things are different there as Ubuntu seems to copy Debian 
pretty closely in general file layout.

Second, while the PyPAD scripts themselves (think of them as ‘user programs’) 
do indeed need to go in ${libdir}/rivendell/pypad (which evaluates to 
‘/usr/lib/rivendell/pypad’ on Debian-is setups), the PyPAD *library module* 
should go in the default system location so it will be in Python’s search path. 
On Ubuntu, this location is ‘/usr/lib/python3/dist-packages’.

N.B. Python supports the concept of having multiple parallel installations of 
different versions, each of which get their own orthogonal module store. On my 
UbuntuStudio 20.04 setup, the default installation has installed no less than 
four different versions of Python, resulting separate module paths for each (in 
my case, ‘/usr/lib/python2.7/dist-packages’, ‘/usr/lib/python3/dist-packages’, 
‘/usr/lib/python3.8/dist-packages’ and ‘/usr/lib/python3.9/dist-packages’). 
These locations appear to be a Debian-ism inasmuch as Automake's 
AM_PATH_PYTHON() macro doesn’t recognize them, instead using the expected 
standard Python defaults. At present, there is a nasty hack in ‘configure.in’ 
(lines 290-305) that attempts to detect this situation and install things the 
‘Debian way’ if necessary. I would love some feedback on how this works on 
various Debian-ish setups (or, even better, PRs that improve the heuristic).


> I've created a copy of the included icecast2.py and also the related 
> icecast2.exemplar. So far the script works, green dot and no errors. A ps on 
> console shows the script running:
> 
> root@debian:~# ps aux | grep pypad
> pypad 4095  3.9  0.1 285108 28624 ?Sl   12:18   2:38 
> /usr/sbin/rdpadengined
> pypad 4097  4.2  0.1 211368 28412 ?S12:18   2:50 
> /usr/sbin/rdrssd
> pypad 9777  0.0  0.1  40812 23948 ?S12:25   0:00 
> /usr/bin/python3 /usr/lib64/rivendell/pypad/pypad_icecast2_8000.py localhost 
> 34289 $1
> root 22462  0.0  0.0   6208   824 pts/1S+   13:25   0:00 grep pypad
> 
> The TCP port for metadata appears listening:
> 
> root@debian:~# netstat -tnlp | grep 34289
> tcp0  0 0.0.0.0:34289 0.0.0.0:*   LISTEN  
> 4073/rdpadd
> 
> 
> I've setup username/password/port/mountpoint on the configuration... 
> apparently, OK... now, the problem:
> 
> I've no song update on the Icecast2 server

Ok, first thing to do is verify that your Icecast2 system will accept metadata 
updates from your PyPAD host. Icecast is famously picky in this regard; updates 
*must* originate (or appear to it to be be originating) from the same source IP 
address as the encoder client originating the stream; updates that fail to meet 
this criterion are ignored. A good way to test this is to attempt to send a 
metadata update *from the same system that is running the PyPAD script* 
manually via a curl(1) command of the form:

curl -u source: 
http://:/admin/metadata?mount==updinfo=

where:

 - The hostname or IP address of the system running Icecast

 - The TCP port number of the Icecast instance

 - The mountpoint of the stream

 - The mount point password.

 - The string to set, encoded as specified in Section 2 of RFC3986

For example, to set a string of "The Beatles - Hey Jude” at an Icecast instance 
running at "icecast.example.com:1234" with a
mountpoint of “MyStream” and a password of “hackme", the URL would be:

curl -u source:hackme 
http://encoder.example.com:1234/admin/metadata?mount=MyStream=updinfo=The%20Beatles%20-%20Hey%20Jude

If this doesn’t work, when sent *from the same system that is running the PyPAD 
setup*, then you have an Icecast setup problem, which will need to be resolved 
before proceeding to configuring the PyPAD stuff.

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| A room without books is like a body without a soul. |
| |
|   

[RDD] Troubleshooting setup of PyPAD

[Alejandro olivan Alvarez]

Hi list!

I'm playing with the PyPAD stuff of Rivendell.

So far, I've managed to have an script running... so far the problems 
I've had to evercome (Debian Stable Buster install) were:


- The documented (on this list) Centos/debianish misplacing of pypad.py 
which needs to be copied to /usr/lib64/rivendell/pypad


 cp /usr/lib/python3.7/site-packages/pypad.py /usr/lib64/rivendell/pypad

- Missing MySQL Python3 module/package

 apt-get install python3-mysqldb


I've created a copy of the included icecast2.py and also the related 
icecast2.exemplar. So far the script works, green dot and no errors. A 
ps on console shows the script running:


root@debian:~# ps aux | grep pypad
pypad 4095  3.9  0.1 285108 28624 ?    Sl   12:18   2:38 
/usr/sbin/rdpadengined
pypad 4097  4.2  0.1 211368 28412 ?    S    12:18   2:50 
/usr/sbin/rdrssd
pypad 9777  0.0  0.1  40812 23948 ?    S    12:25   0:00 
/usr/bin/python3 /usr/lib64/rivendell/pypad/pypad_icecast2_8000.py 
localhost 34289 $1

root 22462  0.0  0.0   6208   824 pts/1    S+   13:25   0:00 grep pypad

The TCP port for metadata appears listening:

root@debian:~# netstat -tnlp | grep 34289
tcp    0  0 0.0.0.0:34289 0.0.0.0:*   LISTEN  
4073/rdpadd



I've setup username/password/port/mountpoint on the configuration... 
apparently, OK... now, the problem:


I've no song update on the Icecast2 server

I've no feedback on syslog either... I'm thinking on reviewing the 
Icecast server log or try to check the connections to Icecast2 server



Any clue on what could I be missing?

Thank you very much in advance.

Best regards.





___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev