Maybe has to do with "time", if the subject was too vague for you. :-) But the problem is weird. When i run mpv, giving it an internet url to stream from, every stream (this is just audio) starts with a current time of -106:45:06 (instead of 0). This results in meaningful seeking being impossible, thus my use of mpv to buffer streams and listen when i like, pause anytime, etc... no seeking works anymore (except, with one or two left arrows, seeking all the way back to the beginning of the stream). But that's not all... playing any video (in falkon) plays the sound ok, but the video either stutters or freezes (then maybe catches up, extremely rapidly... but usually just freezes) while the time indicator does *not* advance. The sound plays normally enough, though.
I have the exact same version of mpv and everything it depends on (as shown by mpv --version) on another laptop and it works normally. The two laptops are almost identical, except for a slightly more recent upgrade on the one not working. I even reverted mpv, ffmpeg, chromaprint to earlier versions but no diff.
One thing i did was run "sudo hwclock --systohc" recently, for no meaningful reason. In trying to figure out my problem, i looked a good deal at this, as the man page warns you not to do this on a running system. Which, basically, as far as i can tell, no one pays any attention to. A big time adjustment can, apparently, potentially cause some obscure problem in rare situations, i guess. Anyway, my hw and system times were close, there was no big adjustment (i run ntpd) and everything with that, as far as i can tell, is fine. I have *no* idea what is going on. Anyone have any sort of clue or idea at all?
It just occurred to me to try to play a video in firefox (which i never use). So i fired it up, tried some bitchute, and also rumble videos. Nothing played. Just sitting at 0:00 time, displaying the pause button (one bitchute is sitting at 0:35 but didn't play at all).
I can't see the hwclock causing this but is it right now ?
sudo hwclock --verbose
It seems to me that if different programs are affected by the same issue you'd think underlying libraries are causing it ?
Yet, to the best of my knowledge, falkon uses different libs than mpv and the most the libs in firefox are static ?
It may be worth quickly creating a new user and seeing if the problems persist there. If they do at least that rules out a configuration problem on the user side and it has to be a system issue.
That's normal with shoutcast streams, and of course you can't seek before when you've started, it's just the timestamp metadata offsetting at the time the server was alive (feed the stream into ffmpeg and it will tell you).
/////
I think the video issues are simply caused by those services being very speed constrained, I advise downloading them with a competent tool for this job like aria2. If you really want to stream something you'd find yt-dlp as a good companion to mpv even in other sites as it has a generic stream extractor. Mozilla i think has further issues with it's standalone player. Falkon is QTWebEngine, a relative of chromium, if it doesn't play something it has to be because of some hardware output/gpu setting, consult chrome://gpu and mess around with some flags.
/////
About the issue with system time I'm not sure if it has that much of an effect on streams themselves as they get counted independently most of the time. Only problem i can think of are https certificates failing with an offset more than 2 minutes IIRC.
To gripped: after reading about hwclock, investigating, messing around (rm'ing /etc/adjtime, recreating...) i left the HW clock in UTC mode (i thought). But just now, i get this:
~$ sudo hwclock --verbose
hwclock from util-linux 2.38.1
System Time: 1679312428.911494
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1678922230 seconds after 1969
Last calibration done at 1678922230 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2023/03/20 11:40:29
Hw clock time : 2023/03/20 11:40:29 = 1679334029 seconds since 1969
Time since last adjustment is 411799 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2023-03-20 11:40:28.911255-06:00
~$
After deleting /etc/adjtime:
~$ sudo hwclock --verbose
hwclock from util-linux 2.38.1
System Time: 1679315128.619317
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2023/03/20 12:25:29
Hw clock time : 2023/03/20 12:25:29 = 1679315129 seconds since 1969
Time since last adjustment is 1679315129 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2023-03-20 06:25:28.621131-06:00
~$
I then put back /etc/adjtime, except changing LOCALTIME => UTC:
~$ cat /etc/adjtime
0.000000 1678922230 0.000000
1678922230
UTC
~$
~$ sudo hwclock --verbose
hwclock from util-linux 2.38.1
System Time: 1679315579.712009
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1678922230 seconds after 1969
Last calibration done at 1678922230 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2023/03/20 12:33:00
Hw clock time : 2023/03/20 12:33:00 = 1679315580 seconds since 1969
Time since last adjustment is 393350 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2023-03-20 06:32:59.710228-06:00
~$
I've gone back and forth editing this because i didn't realize that hwclock reports the time differently when you specify --verbose. Normally, it always reports the localtime. But verbose appears to report the unadjusted time. So, i ran the first hwclock, above at about 5:40am local time, the others around 6:30am. The clocks appear to be in perfect sync, as far as i can tell.
So, to clarify (?):
~$ date; sudo hwclock
Mon Mar 20 07:23:29 AM MDT 2023
2023-03-20 07:23:29.444075-06:00
~$
I created a new user, after trying as root, and get the same result both ways:
~# mpv http://s1.voscast.com:8054/
(+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
[ao/alsa] Playback open error: Host is down
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
[ao/jack] cannot open server
[ao] Failed to initialize audio driver 'jack'
Could not open/initialize audio device -> no sound.
Audio: no audio
Exiting... (Errors when loading file)
~#
I haven't done that before, so i'm not sure why there's no audio. My normal audio situation is that i'm running pipewire, et al, as my normal (craig) user:
~$ show wire
craig 1146 1106 0 Mar19 ? 00:00:00 /usr/bin/bash -c pipewire & pipewire-pulse & wireplumber
craig 1149 1146 0 Mar19 ? 00:04:09 pipewire
craig 1150 1146 0 Mar19 ? 00:02:10 pipewire-pulse
craig 1151 1146 0 Mar19 ? 00:00:01 wireplumber
~$
So maybe that's a problem? Just as one thing to try, i added the new user (test) to the audio group, but no diff.
To hitman... there's nothing "normal" about the current behavior i'm seeing. As i said, on my other laptop, with the exact same versions of mpv, libavutil, libavcodec, libavformat, libswscale, libavfilter, libswresample and ffmpeg installed it plays fine (stream starts at 0:00). Also, video playback in falkon & firefox is not even remotely "normal". Normally, videos play fine most of the time. Now, as i said, falkon plays the audio, but the time display does not advance and the video is mostly frozen. In firefox, nothing plays at all. All these problems began, recently, at the same time. In falkon, with the video "playing", when i click on the time bar, the time display updates to the corresponding time, and the video updates to that frame, the sound plays from that point, but neither the video (frame) nor the time counter change from that point. I am *so* mystified.
I think, but of course could be wrong, that the hwclock train of thought is a red herring.
mpv http://s1.voscast.com:8054/
Resuming playback. This behavior can be disabled with --no-resume-playback.
(+) Audio --aid=1 (mp3 2ch 44100Hz)
AO: [pipewire] 44100Hz stereo 2ch floatp
Working fine here.
Yours
[ao/pipewire] Could not connect to context '(null)': Host is down
[ao/alsa] Playback open error: Host is down
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
[ao/jack] cannot open server
It's a pipewire problem it seems.
Host is down ?
Lots of mentions of Jack. Do you use Jack ? You don't mention it.
try using streamlink (https://streamlink.github.io/) . try flags mentioned in examples in man page of program.
I didn't say that, only about the audiostream i referred to as being normal
I'm willing to bet this is not the case, i have used online radio for years on all kinds of devices, you're not playing the same stream.
Just to clarify, the failure of mpv to play that i last posted (that includes "jack errors") was my attempt at running from a *new* user (or root... same result). When i run it as i normally do, you see this:
~$ mpv --no-config http://s1.voscast.com:8054/
(+) Audio --aid=1 (mp3 2ch 44100Hz)
AO: [pipewire] 44100Hz stereo 2ch floatp
A: -106:45:06 / 00:00:27 (0%) Cache: 25s/775KB
Exiting... (Quit)
~$
I don't know why it wouldn't play under another user. I've never used jack on this system (as any user). The only jack thing that is installed is jack2, which was installed as a dependency. As far as it being the "same" stream, or not, i've run mpv with the same url at almost the same time on both laptops. The output on my other, right now (as is typical) is:
~$ mpv --no-config http://s1.voscast.com:8054/
(+) Audio --aid=1 (mp3 2ch 44100Hz)
AO: [pipewire] 44100Hz stereo 2ch floatp
A: 00:00:01 / 00:00:27 (5%) Cache: 25s/775KB
Exiting... (Quit)
~$
One thing i sometimes do, instead of streaming, is do something like:
wget http://s1.voscast.com:8054/ -O pgm.mp3
I did this on both laptops and played each fragment on both laptops. Both fragments, on my laptop exhibiting the problem, behave exactly as if i passed the url to mpv directly, starting playback at -106:45:06. Playing either back on the laptop that still works properly, behaved normally as well:
~$ mpv --no-config tst-lemur.mp3
[ffmpeg/demuxer] mp3: Estimating duration from bitrate, this may be inaccurate
(+) Audio --aid=1 (mp3 2ch 44100Hz)
AO: [pipewire] 44100Hz stereo 2ch floatp
A: 00:00:01 / 00:00:36 (3%)
Exiting... (Quit)
$~
If, on the working laptop, i didn't specify "--no-config" i got this:
~$ mpv tst-lemur.mp3
[song_change] The 'idle' event is deprecated and will be removed.
No playlist
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
1: tst-lemur.mp3 nil
Could not open/initialize audio device -> no sound.
Exiting... (Errors when loading file)
No current playlist position
(+) Audio --aid=1 (mp3 2ch 44100Hz)
~$
I've never seen this behavior before. On the laptop with the problem, it runs the same (starting at -106:45:06) with or without "--no-config".
I appreciate the extra eyeballs, still mystified though i am.
That would suggest that pipewire wasn't running in the new user session. Whatever steps you take to start pipewire as the normal user would have to repeated as the new user.
It probably won't help. It's just something I tend to do myself when befuddled. Rule out user settings.
Maybe clutching at straws but in case you are not aware you can up mpv's log level.
mpv --msg-level=all=debug http://s1.voscast.com:8054/
or insanity mode
mpv --msg-level=all=trace http://s1.voscast.com:8054/
I normally run pipewire, pipewire-pulse, and wireplumber which gets my sound working. I tried to run these, logged in as root, and got all sorts of errors, plus the helpful suggestion that i should set some environment variable, giving 3 possibilities. As my normal user i saw one suggestion, XDG_RUNTIME_DIR was set for my normal user to be /run/user/1000. So as root, i did:
export XDG_RUNTIME_DIR=/run/user/1000
and, bingo, mpv played. With the same -106:45:06 starting point. I'm thinking that if there is something in pipewire that is doing this (i've no better ideas) i probably just used the running pipewire from my normal user. So that doesn't seem like a strong clue about anything. I've also tried running with the insane amount of debug information and all i see is that it starts decoding packets, and, bingo, it outputs that same negative starting time. It's getting this from a bit of stream i saved with wget, on disk. Offsets in that are understood to be rather free-floating but... it didn't use to behave this way. And the same version of mpv and other dependent programs/libraries on another laptop *doesn't*. With the same input file, it behaves differently. It seems this problem precedes the point of audio output, so pipewire wouldn't really *seem* to have anything to do with it. I'm completely at a loss. Thanks for the help, though.
I'm thinking of comparing the list of packages installed on each laptop. I'm sure that will waste a fair amount of time. :-)
P.S. I listen to audio streams much more than watch videos, so the fact that video playing is also messed up slips my mind sometimes. But this symptom is probably more "serious".
I replaced pipewire-alsa with pulseaudio-alsa and mpv now starts streaming at 0, and videos play properly. I replaced pulseaudio-alsa with pipewire-alsa and it was broken again, exactly as described. I reinstalled pulseaudio-alsa again and it wasn't working properly until i realized that, although the pipewire-alsa package had been removed, pipewire and pipewire-pulse were still running. I killed them and things were working again.
I'm wondering if my laptop that didn't have this problem was because i haven't rebooted it recently and i might not be running what i think it's running? Although, looking, it's running pipewire, pipewire-pulse and wireplumber. Additionally, i discovered that the laptop that worked all along never had pipewire-alsa or pulseaudio-alsa installed. It appears that, if you install pipewire-alsa you then *have* to run pipewire and pipewire-pulse as well. Or with pulseaudio-alsa installed, i suppose you have to run pulseaudio. But without either, am i basically running directly through alsa? No audio server seems to be running. But it's working fine now, with both pipewire-alsa and pulseaudio-alsa removed. These packages have all been updated recently, which might have created some subtle problems.
I'm marking this unsolved. I still have severe pipewire issues. I can get around them, principally by playing (falkon) videos and streaming audio via mpv without pipewire running (and pipewire-alsa not installed). With my mixer plugged in, i have to run pipewire, and i can patch things together... except that doesn't play nicely with mpv or falkon. mpv either doesn't advance from 0, errors on startup because of driver issues, starts from -106:44:07, videos don't play. I have to reboot to get (certain) things to play properly one way or another.
I posted an issue at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3155
and someone asked if this was a regression, to which i responded:
Then i got this followup response:
I've made no other progress on this. The above seems like a reasonable supposition but other than reinstalling the entire O/S, i don't have a good idea as to how to eliminate some kind of O/S issue specific to my installation.
A note i had made, taken from:
https://wiki.archlinux.org/title/WirePlumber
said that default settings could be restored by deleting the contents of
~/.local/state/wireplumber/So, i tried deleting this directory and, *voila*, everything works properly now!
After having this audio interface for over 3 months now... i can finally start using it!