Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Weirdest Pipewire problem (Read 1599 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[SOLVED] Weirdest Pipewire problem

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).

Re: Weirdest problem

Reply #1
I can't see the hwclock causing this but is it right now ?
Code: [Select]
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.

Re: Weirdest problem

Reply #2
Quote
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).
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.

Re: Weirdest problem

Reply #3
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:
Code: [Select]
~$ 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:

Code: [Select]
~$ 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:
Code: [Select]
~$ cat /etc/adjtime 
0.000000 1678922230 0.000000
1678922230
UTC
~$

Code: [Select]
~$ 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 (?):

Code: [Select]
~$ 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:
Code: [Select]
~# 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:

Code: [Select]
~$ 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.

Re: Weirdest problem

Reply #4
I think, but of course could be wrong, that the hwclock train of thought is a red herring.

Code: [Select]
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
Code: [Select]
[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.

Re: Weirdest problem

Reply #5
try using streamlink . try flags mentioned in examples in man page of program.

Re: Weirdest problem

Reply #6
Quote
Also, video playback in falkon & firefox is not even remotely "normal"
I didn't say that, only about the audiostream i referred to as being normal
Quote
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).
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.

Re: Weirdest problem

Reply #7
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:

Code: [Select]
~$ 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:

Code: [Select]
~$ 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:
Code: [Select]
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:

Code: [Select]
~$ 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:

Code: [Select]
~$ 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.

Re: Weirdest problem

Reply #8
Quote
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).
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.
Code: [Select]
mpv  --msg-level=all=debug http://s1.voscast.com:8054/
or insanity mode
Code: [Select]
mpv  --msg-level=all=trace http://s1.voscast.com:8054/


Re: Weirdest problem

Reply #9
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".

Re: Weirdest problem

Reply #10
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.

Re: Weirdest Pipewire problem

Reply #11
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.

Re: Weirdest Pipewire problem

Reply #12
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:

Quote
I was able to downgrade... to 1:0.3.67-1, to 1:0.3.66-2 and even to 1:0.3.65-6 (these were the versions i still had in the package cache) the last requiring me to delete libpipewire (i guess this was introduced with 3.66).  All misbehaved in the same way, as described. I should add that, although i had earlier versions installed, i didn't start running them (when i finally realized that they weren't being run...) until i was on, probably, 3.66 (briefly before 3.67 upgrade).

Then i got this followup response:

Quote
Have you asked your distro for help? I'd suggest that this is more likely to be a distro integration issue rather than a PipeWire bug. After all, there's plenty of mpv and Firefox users out there with PipeWire as the audio daemon, so, if it was a general issue, I'm sure someone else would have reported this long ago.

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.

 

[SOLVED] Re: Weirdest Pipewire problem

Reply #13
A note i had made, taken from:

Code: [Select]
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!