search

vidify / old-audiosync

First implementation of the audio synchronization feature for Vidify, now obsolete
GNU Lesser General Public License v3.0
17 stars 3 forks source link

Stream not moved if vidify started before spotify #48

Closed Nowa-Ammerlaan closed 4 years ago

Nowa-Ammerlaan commented 4 years ago

Hello,

I've just now upgraded to vidify-audiosync-0.2, and I've been checking out the new dedicated pulseaudio monitor (from issue https://github.com/vidify/audiosync/issues/22). It's working amazing thank you so much.

One small thing I did notice is that if vidify is started before spotify (which happens on my system because both are set to autostart at login, but spotify is slow to start and vidify is fast) the loopback and virtual sink are setup correctly but the spotify stream is not moved to the audiosync sink. It works just fine if I close and restart vidify, and then it stops working again if I close and restart spotify. The issue (I think) is that vidify-audiosync sets up the loopback and virtual sink modules when it starts, and then tries to move the stream to audiosync.monitor but the stream is not yet available so that fails. When the stream does become available it doesn't recheck and move the stream.

To accommodate for the situation that vidify is started before the player (spotify). Might I suggest to either: Wait with running audiosync.setup(stream_name) until the player reports that it is playing ( MediaPlayer2.Player PlaybackStatus == 'Playing'). Or to re-run audiosync.setup(stream_name) (or just the part that move's the stream) as soon as the player reports that it is now playing( MediaPlayer2.Player PlaybackStatus == 'Stoped' or 'Paused' --> MediaPlayer2.Player PlaybackStatus == 'Playing')

marioortizmanero commented 4 years ago

Hey Andrew,

Thanks for reporting the issue. The dedicated sink is initialized with audiosync.setup(), inside the audiosync worker constructor, which is only called once. This happens only once the connection has been established successfully. For this, the player has to be available and playing something. The whole sink initialization also happens all at once inside the setup function, so all the steps are executed sequentially inside the same function. That's why I think it has to be something different.

One thing I do have to fix is the edge case where play_video is called with a new song, but it's paused. The audiosync recording/downloading is only paused/continued when change_video_status is called, so in case it already starts paused, it doesn't work.

Can you please share some logs with --debug? Thanks!

Nowa-Ammerlaan commented 4 years ago

That's why I think it has to be something different.

I did some more testing, and it does indeed work when vidify is started before spotify. It is actually the restarting that is the problem: 1) start vidify 2) start spotify, stream gets moved to audiosync correctly 3) close spotify 4) restart spotify, stream does not get moved and stays on default

There is also something strange going on with autostarting, because the moving did not work when I logged in, only after I manually restarted vidify did it start working. However, that might be something different, I'll do some more investigating on this tomorrow to see if I can find out why this does not work if vidify is autostarted.

Can you please share some logs with --debug? Thanks!

vidify-debug-log.txt

marioortizmanero commented 4 years ago

I did some more testing, and it does indeed work when vidify is started before spotify. It is actually the restarting that is the problem:

Vidify currently doesn't support multiple Spotify sessions (or any MPRIS player). I had an issue open to address this at https://github.com/vidify/vidify/issues/59. But when I was going to implement it, I saw that it'd be overly complicated and only available for Linux anyway. I'll definitely do it someday, but I don't see it as something important right now (IMO).

There is also something strange going on with autostarting, because the moving did not work when I logged in, only after I manually restarted vidify did it start working. However, that might be something different, I'll do some more investigating on this tomorrow to see if I can find out why this does not work if vidify is autostarted.

I'll also look into it in detail soon and update this. I haven't actually tried to reproduce the issue yet.

marioortizmanero commented 4 years ago

Just tested it and I can't reproduce the original issue. For what I saw in the log, it seems that it's only about multiple Spotify sessions while Vidify is open, then. As I said, it'll be done in the future. But it has nothing to do with audiosync, anyway, so I'm closing this.

Thanks for the report!

Nowa-Ammerlaan commented 4 years ago

Just tested it and I can't reproduce the original issue. For what I saw in the log, it seems that it's only about multiple Spotify sessions while Vidify is open, then. As I said, it'll be done in the future. But it has nothing to do with audiosync, anyway, so I'm closing this.

I'm very confused, I booted up my PC today and audiosync was working just fine. I thought maybe the issue I observed yesterday was due to the internet not being available at that time, but I tested that and that is not it either.

So I'm very confused about what was going on yesterday that is not happening today. Anyway I can't reproduce this either, but I'll let you know if this autostarting issue comes back.

About the multiple sessions thing, vidify seems to work just fine if I close and restart spotify (video plays, lyrics are shown), it's just the audiosync part that stops working when I do that. (recording stream is still on audiosync.monitor, but the spotify stream is no longer on the audiosync sink). Anyway, that is not really important, as in general spotify isn't closed and restarted while vidify is running. The only reason I brought it up was because I thought it might be related to the autostarting issue I was experiencing. But, as I said, I don't know what was going on with that yesterday, it is working fine now.

Also, unrelated to this, but I have given up on my attempts to merge my vidify ebuilds into gentoo's main repository :disappointed: . The amount of PR's at the moment is huge, and the devs are giving priority to PRs that touch already existing packages (can't really blame them, with almost 475 PRs). Instead I've pushed my ebuilds to the GURU overlay, it is to gentoo sort of what AUR is for arch. The ebuilds are in the dev branch at the moment (meaning they are not yet available for the end user), but hopefully the dev branch will get merged into the master branch soon :smile: .

marioortizmanero commented 4 years ago

Hahaha I made a few commits today so I might have fixed the issue unintentionally.

Thanks for the efforts on uploading it to Gentoo! Should I change the URL in the readme? Or maybe it's better to wait until it's in master?

I still have to get the snap working myself... It's awfully complicated :/

Nowa-Ammerlaan commented 4 years ago

Thanks for the efforts on uploading it to Gentoo! Should I change the URL in the readme? Or maybe it's better to wait until it's in master?

I think we should wait for a bit, as the ebuild is not (easily) accessible yet. I can make a PR with installation instructions and the correct link when it gets merged to master. (it's just one extra command to add the guru overlay: eselect repository enable guru && emerge vidify) Once it is in the master branch it should show up here too: https://gpo.zugaina.org/ (which is the overview page for all gentoo repositories and overlays)