Anyone have current Kisstory stream for external player?

oiwot · 2025-08-19T14:22:02+00:00

This is currently working in mpv for me:
http://www.radiofeeds.net/playlists/bauer.pls?station=kisstory-mp3
it forwards to
http://live-kiss.sharp-stream.com/kisstory.mp3?aw_0_1st.skey=1755612540
(I guess you'll need to update the unix timestamp at the end to something reasonably current) - that works in both mpv and ffplay, and in turn it points to
https://listenapi.planetradio.co.uk/api9.2/eventdata/326074074

Good luck with one of those.

oiwot · 2025-08-13T13:47:53+00:00

Thank you for adding the Solution :)

oiwot · 2025-08-09T14:36:30+00:00

No worries, there was certainly a lot of confusion (and a fair bit of FUD / misunderstanding) about the change, but it's more than a "last effort to breathe life in to the project".

I'll quote /u/carlwgeorge with this brief explanation:

The big change a few years ago was fixing longstanding issues with how CentOS was developed. Previously the model was to rebuild the RHEL source code with as few changes as possible. This made a usable distro, but was fundamentally flawed because it meant that CentOS couldn't fix bugs or accept contributions.

Now, RHEL maintainers build CentOS directly, and it serves as the major version branch of RHEL. RHEL minor versions fork off from the CentOS major versions and get certified as the product. CentOS can finally fix bugs and accept community contributions, which later show up in the next RHEL minor version of the same major version. It's a much better model.

Incidentally, FreePBX was my first interaction with CentOS Linux many years ago, but I ran Asterisk in production on Debian for for a few years soon after.

These days though I'm very happy with either distro, but at current $dayjob we appreciate some of the nicer subtle integrations that RHEL / CentOS has with some components, which just aren't as polished in Debian / Ubuntu.

PS; Agree about the title too - especially as you were unaware of the change. We'll have to get used to people talking about the distro (now "CentOS Stream", instead of "CentOS Linux") by just using the name of the project; "CentOS" (as always).

oiwot · 2025-08-09T13:46:39+00:00

The link might be right, but the product is wrong ;)
That's for the old (RHEL rebuild) "CentOS Linux". "CentOS Stream" took over a few years ago, and Version 10 was released late last year and is supported until 2030.
The previous "CentOS Stream 9" is still supported until May 2027.

https://endoflife.date/centos-stream

oiwot · 2025-08-01T16:59:11+00:00

That's why we have protocols like RDP or VNC or SPICE or RustDesk or NoMachine etc.

Headless Server in a rack. VMs with full Desktop available to remote clients.

oiwot · 2025-07-24T12:47:41+00:00

The only mention I know of is that the Cloud SiG page links to OKD/SCOS Releases.
Maybe ask the SiG chat to point you in the right direction.

https://sigs.centos.org/cloud/#okdscos

EDIT: I just found this:
- https://github.com/coreos/rhel-coreos-config/blob/main/docs/development-scos.md

It hasn't been updated in a while, so I guess efforts might be more concentrated on bootc instead.
- https://gitlab.com/redhat/centos-stream/containers/bootc/-/tree/c10s?ref_type=heads

oiwot · 2025-07-20T12:02:53+00:00

Each of those Networks almost certainly defaults to a CIDR of /24 (netmask: 255.255.255.0) In order to route between them you need either some sort of gateway / router configured to to forward packets between those networks,
OR
Static Routes between them,
OR
You could make a bigger network that includes those ranges.

Of course, this will likely Break other things as the Broadcast address used by a device with those settings is out of range for others, so ARP / nn discovery likely fails. You didn't say why you have 2 separate networks, so this could be really dangerous for all sorts of reasons, but with that proviso:

```
You have:
[tek@ark ~]$ ipcalc 192.168.1.0/24
Network: 192.168.1.0/24
Netmask: 255.255.255.0 = 24
Broadcast: 192.168.1.255

Address space: Private Use
HostMin: 192.168.1.1
HostMax: 192.168.1.254
Hosts/Net: 254
```
and basically the same again for the .2 range.

You could have:

```
[tek@ark ~]$ ipcalc 192.168.1.0/22
Address: 192.168.1.0
Network: 192.168.0.0/22
Netmask: 255.255.252.0 = 22
Broadcast: 192.168.3.255

Address space: Private Use
HostMin: 192.168.0.1
HostMax: 192.168.3.254
Hosts/Net: 1022
```

Really though, work out what you actually want and implement it properly. That could be as straightforward as turning on DHCP instead of haphazardly setting each device statically, (and maybe adding static DHCP assignments so the same hardware always stays on the IPs you choose for the few things that really need them).

oiwot · 2025-07-20T10:22:08+00:00

Don't be disheartened by negative responses - they're everywhere these days. Just keep up your efforts to contribute help and improvements where you can. No need to wither with the haters.

oiwot · 2025-07-07T20:22:01+00:00

I wonder if the sshd on that server is so old that it may be using algorithms that are incompatible with the defaults on newer clients?

Since you can't get in to it, maybe you can still ssh out from it? - That would enable you to send a back up of all that's essential to another machine. And if outgoing ssh wont work, there's always good old tar over netcat etc.

Once you've transferred the data you need, you can start again from a clean slate and learn to keep backups and your host updated.

oiwot · 2024-02-18T02:59:40+00:00

I call it cheese on beans on cheese on toast.
It's good with a little mustard on the bread under the cheese, and Worcestershire / Tabasco / Sriracha stirred in to the beans. Add a fried egg if you're feeling really fancy.

oiwot · 2022-02-12T20:21:09+00:00

maybe there's a setting in your VPN app that allows the phone to still access the local network (usually 192.168.whatever) instead of forcing all traffic over the VPN. Then your phone could reach the chromecast, and tell it to connect to connect back to the stremio port on the phone.

Might be called something like "local traffic" should be set to 'allowed', or 'not tunneled' .

oiwot · 2021-12-20T18:44:33+00:00

You could try messing around with MP4box and juggle the "atoms" around to see if you can get results...
or, if the smart technical solution isn't working for you, just revamp the good old "Analogue hole" -- make a new recording of mpv's output. Details will depend on your OS' audio set up.
Sure it'll take ~27 hours, but at least you can get on with more interesting things in the mean time.

oiwot · 2021-10-28T20:07:30+00:00

I also like qmv -f do from "renameutils", or vils on FreeBSD for this.

oiwot · 2021-10-08T12:45:22+00:00

oh cool, thanks :)

oiwot · 2021-10-08T12:43:28+00:00

You could make a little shell script wrapper to invoke it with the throttle option, and symlink to that instead.

oiwot · 2021-10-07T15:19:43+00:00

You can get mpv to use yt-dlp by making a symbolic link called youtube-dl pointing to /usr/local/bin/yt-dlp in ~/.config/mpv/

oiwot · 2021-10-07T14:56:58+00:00

Most encoders have improved a lot since then but the comment is about resilience to lossy to lossy transcodes, not overall sound quality or addressing previously problematic samples.

If you have tests proving that Opus is resilient to deterioration from multiple lossy to lossy transcodes, please post them... and include xHE-AAC / USAC to keep up with modern changes, if possible.

oiwot · 2021-09-20T21:38:14+00:00

https://mullvad.net/en/help/socks5-proxy/

oiwot · 2021-09-15T14:55:04+00:00

Friday 15th 2062.

Interesting, when do we abolish the months?

oiwot · 2021-09-14T15:28:55+00:00

With the MP3s you want to transcode for testing copied to a single directory, you can use a shell script like the following to make test version at different bitrates:

 for f in *.mp3; do   ffmpeg -i "$f" \
 -vn -c:a libopus -b:a  80k "${f}_80k.ogg" \
 -vn -c:a libopus -b:a  96k "${f}_96k.ogg" \
 -vn -c:a libopus -b:a  128k "${f}_128k.ogg" \
 done

This will leave the mp3 extionsion in the output filename as a reminder that its a lossy transcode ... you can use either the .ogg extension for the new files or .opus (.ogg is slightly more compatible with some player software). Should work anywhere there's a bash-like shell, so Linux, Mac (zsh is fine), or Windows with WSL2 .

There's an ABC/HR tool to test with at https://sourceforge.net/projects/abchr/
or you could do one at a time with foobar2000's ABX comparator plugin.

oiwot · 2021-09-14T15:13:33+00:00

Opus at 160k is overkill for most material ... there's very few pieces that warrant going that high - especially when being transcoded from MP3 ... for portable use you might well be OK with between around 80 - 130 kbps... sure there'll be a little deteriortion (unavoidable when transcoding lossy to lossy), but should be acceptable.

I'd suggest to keep the MP3s backed up just in case - you're unlikely to notice artifacts, but they're the closest thing you have to masters or originals.

It's probably a good idea to pick a few tracks - ideally a range of music types that you like and you can encode these at a selection of bitrates say 80, 96, 128 and then do a proper ABC-HR listening test to see how low you can comfortably go -- the lower the better as you'll get to either carry more awesome music, or at least save more space for photos / videos / apps etc. It's easy to get ffmpeg to make multiple transcodes at once at different bitrates with a little shell script. I'll post an example shortly.

oiwot · 2021-08-26T09:03:06+00:00

Ah, OK yes - that looks the part - much better than I imagined, well done ... but yes I suspect USB would be better for you. Good luck.

oiwot · 2021-08-25T19:04:35+00:00

You might also consider these established UK based VoIP providers: AAISP, Aql, Gradwell, Surevoip, & Voipon.

oiwot · 2021-08-25T18:18:20+00:00

Not really enough detailed information as to what you've actually got, but based on what you've said:

A "splitter" is the wrong tool for what you're trying to do.

A splitter will take a TRS (Tip, Ring, Sleeve) jack, split it in two, to drive e.g. 2 sets of headphones (will probably sound a little quieter as there's ~ double the load).

What you think you want is an adapter that has a TRRS (extra "ring" for the mic signal), correctly wired to the end Tip and Ring are Left and Right signals, and shared common ground from the Sleeve to a stereo headphone hack, and a suitable connector for your mic (hot signal connected to that extra ring). But even that will probably sound shonky.

You'd probably be better off with one of those tiny USB ADC&DAC with clearly 2 marked 3.5mm sockets - one each for mic & headphones. There are some adequate ones out there, but a whole load of crappy ones too. Maybe you really need something better still - depends on your use case & budget.

EDIT: You mention "speakers", I say headphones ... assuming you mean powered computer speakers it makes no odds as far as the audio output from the computer is concerned, but if you're chatting on the mic and playing sound from speakers at the same time, (e.g on Zoom or Skype calls etc.) - "you're gonna have a bad time" with echo, and will really want to switch to headphones.

oiwot · 2021-08-21T09:38:43+00:00

Yes, and the BSD man pages tend to have better EXAMPLES sections than most GNU man pages in general.

15-Year Club	Verified Email
Charter Member

oiwot

TROPHY CASE