On Jul 2, 2021, at 07:54, Alejandro olivan Alvarez
<alejandro.olivan.alva...@gmail.com> 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 ? 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:<password>
http://<hostname>:<tcp-port>/admin/metadata?mount=<mount-point>&mode=updinfo&song=<string>
where:
<hostname> - The hostname or IP address of the system running Icecast
<tcp-port> - The TCP port number of the Icecast instance
<mount-point> - The mountpoint of the stream
<password> - The mount point password.
<string> - 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&mode=updinfo&song=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. |
| |
| -- Cicero |
|---------------------------------------------------------------------|_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
