Often not showing Boostagram controls when applicable

[dwvisser]

Describe the bug On iOS, When I play a new episode of one of my V4V podcasts, e.g., https://podcastindex.org/podcast/575694, it will often not display the "streaming sats" and "boostagram" controls. Sometimes if I pause, leave the app, and come back after a time, the controls are then there.

To Reproduce Steps to reproduce the behavior:

1. Go to "Episodes" tab
2. Select a recently downloaded V4V podcast episode.
3. Playback screen doesn't show sats controls as expected.

Expected behavior Playback screen always shows sats controls for Lightning-enabled podcasts.

Smartphone (please complete the following information):

• Device: iPhone 13
• OS: iOS 16.3.1
• App Version: 4.12.2 Build 2088

[mitchdowney]

@dwvisser thanks for the bug report. Hmm I am unable to reproduce this issue unfortunately. Have you subscribed to Linux Unplugged by searching for it in Podverse, or added it by RSS URL? The add by RSS podcasts have reduced feature support. That might not be the problem though.

A few people have reported similar problems though it's more than an edge case. I'll see if I can add something to try to prevent it in the next release, but it will be difficult to fix until I can reproduce the issue.

[dwvisser]

Have you subscribed to Linux Unplugged by searching for it in Podverse, or added it by RSS URL? The add by RSS podcasts have reduced feature support. That might not be the problem though.

I'm pretty sure I searched in Podverse. I was completely unable to import OPML from Castamatic for some reason. Here is a screenshot of the subscribed podcast on my client:

[dwvisser]

Well, today, https://podcastindex.org/podcast/487548 just worked with sat streaming. 🤞🏻that this continues. 😊

[mitchdowney]

@dwvisser hmm well that's good if it's not happening anymore, but I wish I knew what happened lol it seems like there must be a race condition causing the bug to only happen occasionally.

[dwvisser]

On the theory that the issue might have to do with (possibly temporary) feed data, I should report that right this moment, I have no sat streaming/boost controls when playing this podcast: https://podcastindex.org/podcast/5049889

[dwvisser]

On the theory that the issue might have to do with (possibly temporary) feed data,

…or with their Lightning channels?

[mitchdowney]

@dwvisser this really has me stumped...I have never run into this on my iPhone XR and I listen to podcasts with V4V streaming on a lot. I just played 5 episodes of Bitcoin Dad Pod on it and the V4V buttons remained available on the Player screen.

Obviously something is causing the problem for you though...

Question: when the issue happens, what do you see when you go to More > Value for Value (V4V)? Does it show Alby is "Connected"? If yes, and if you tap Alby, does it show you your wallet info and how many sats are in it?

Also, do you use a Lightning wallet provided by Alby? Or did you connect your own Lightning node to Alby? I have only ever used the default Alby wallet.

[dwvisser]

Question: when the issue happens, what do you see when you go to More > Value for Value (V4V)? Does it show Alby is "Connected"? If yes, and if you tap Alby, does it show you your wallet info and how many sats are in it?

I'll have to answer this when the problem pops up again. At present, still playing back same podcast, the sats controls appeared about 20 minutes into the episode, and are still there. The wallet shows as connected, and having 59412 sats.

Also, do you use a Lightning wallet provided by Alby? Or did you connect your own Lightning node to Alby? I have only ever used the default Alby wallet.

Default Alby wallet. I considered connecting my own node, but decided I like the default for my V4V activities.

[mitchdowney]

@dwvisser thank you. It seems likely there is a race condition. This line here at least should grab globalState after the await that proceeds where it is at currently: https://github.com/podverse/podverse-rn/blob/develop/src/state/actions/v4v/v4v.ts#L347

I can change that in v4.12.4. Not sure that's the source of the problem though...

If notice any other patterns please let me know.

[dwvisser]

@dwvisser thank you. It seems likely there is a race condition. This line here at least should grab globalState after the await that proceeds where it is at currently: https://github.com/podverse/podverse-rn/blob/develop/src/state/actions/v4v/v4v.ts#L347

An opportunity for me to level up on my modern JS/Typescript understanding. 😁 I'll study this function later.

[mitchdowney]

@dwvisser cool well be careful...I am not the best role model for modern JS/TypeScript 😂

[dwvisser]

This is probably unrelated, but I thought I should ask: I don't see an explicit check on the optional parameter anywhere, e.g.:

if (typeof(preventPlayerUpdate) !== 'undefined') {
   // foo
} else {
  // bar
}

On the line, if (!preventPlayerUpdate && nowPlayingItem) {, how does the optional boolean parameter preventPlayerUpdate evaluate if not provided?

[mitchdowney]

@dwvisser I changed the order of that one asynchronous issue and it will be in v4.12.4: https://github.com/podverse/podverse-rn/commit/bdfdf431856c96baaf3b55291b5aa8bb9d490878

But...I have no idea if that will actually fix your issue. I just know that line was a problem and might be related.

RE: typeof undefined...I think that is more explicit than JavaScript cares about. If the optional parameter is not provided, then its value will be undefined, and if (!preventPlayerUpdate) will not be a problem for it. undefined is handled as a falsey value inside conditionals in javascript.

[dwvisser]

@dwvisser I changed the order of that one asynchronous issue and it will be in v4.12.4: https://github.com/podverse/podverse-rn/commit/bdfdf431856c96baaf3b55291b5aa8bb9d490878

But...I have no idea if that will actually fix your issue. I just know that line was a problem and might be related.

I think the fix is plausible. When my phone has that version or later, I'll keep you posted on whether the issue goes away or not.

[dwvisser]

Unfortunately, this morning I confirmed I have v4.12.4, but this issue is still happening. 🧐

[mitchdowney]

Have you been able to test this condition?:

Question: when the issue happens, what do you see when you go to More > Value for Value (V4V)? Does it show Alby is "Connected"? If yes, and if you tap Alby, does it show you your wallet info and how many sats are in it?

Unfortunately I am all out of ideas for how to debug this. You're the only person reporting this issue at the moment, and I'm just not able to figure out how to reproduce the issue. It's also not 100% this issue is within our control to solve as if Alby returns an error response from their server, then our app will not render the V4V controls.

[mitchdowney]

For what it's worth, in case some one else has time to reproduce and debug the issue, here is where V4V gets initialized in global state. Again until I'm able to reproduce the issue I don't know what I can do to help here. If someone needs help setting up a local environment to work on the app please let me know.

https://github.com/podverse/podverse-rn/blob/develop/src/state/actions/v4v/v4v.ts#L77

[dwvisser]

Have you been able to test this condition?:

Question: when the issue happens, what do you see when you go to More > Value for Value (V4V)? Does it show Alby is "Connected"? If yes, and if you tap Alby, does it show you your wallet info and how many sats are in it?

On another podcast (LUP again), I see the issue, then go see that my Alby wallet is, indeed, connected.

This discussion gave me an idea, and I believe I have a workaround that may be a clue to reproduction and/or a fix. Steps:

1. See the issue, I.e., start playing a V4V podcast where Boostagram controls aren't showing as they should.
2. Pause playback.
3. Swipe the Podverse app "up out of memory"
4. Relaunch Podverse. You should see that most recently played podcast at the bottom of the screen.
5. Select the …More tab
6. Select Value 4 value (V4V)
7. Select your Alby wallet to view the balance screen
8. Press the play button on the screen podcast control at the bottom of the screen. You should now be able to see your Boostagram controls when viewing the episode playback screen.

It only seems to work reliably with the bottom-of-screen playback control. Navigate to other podcasts and Boostagram control might break again.

[mitchdowney]

@dwvisser thanks again.

Can you reach out to michael@getalby.com with your Alby account that you are experiencing the issue with? @bumi offered to take a look and see if he notices anything unusual about your account.

But in the meantime...I'm still pretty stumped, but maybe I can add an extra call to handle the V4V state. It sounds like that function gets called along the way in your steps, which ends up in fixing the issue. I'm not sure how it's getting missed in the first place but...calling the same function again later shouldn't cause an issue.

[mitchdowney]

@dwvisser are you still running into this issue? (if you're still using podverse?)

[dwvisser]

@dwvisser are you still running into this issue? (if you're still using podverse?)

I'm still using Podverse. 🙂 It still happens (not all the time). My client shows up-to-date version 4.12.7 build 2128. The good news is, my workaround is reliable when it happens.

[mitchdowney]

@dwvisser ok thanks. I am curious, do you know if these steps are definitely necessary for your work around?

Relaunch Podverse. You should see that most recently played podcast at the bottom of the screen. Select the …More tab Select Value 4 value (V4V) Select your Alby wallet to view the balance screen

So, just closing and restarting the app is not enough to workaround the bug for you? You have to go to More > V4V > Alby > play?

In any case, I'm going to look into this today and see if I can identify anything that'd explain the bug...

[dwvisser]

I can say that the last time the issue showed, that restarting alone didn't bring up the correct view on playback screen.

I tried to reproduce just now and couldn't get it to happen. A few days ago, I replaced my old unreliable (for our iOS devices anyway) Wi-Fi 5 mesh system with a fancy new Wifi 6E mesh system, so maybe connectivity has something to do with it? It's possible that the last time I saw the issue, I was out and about relying on my MVNO's connectivity (Mint Mobile), which isn't always perfect.

[mitchdowney]

@dwvisser hmm networking issues could definitely be related to the issue (and I know nothing about mesh systems lol they sound cool though), because if the app makes a failing network request to Alby when loading a value-enabled podcast in the player, then the app will think you are not logged in, and not render the value buttons.

The buttons should still render though even if a network request fails (the boosts and streams should instead fail until you have internet connectivity again). I'll see if I can make it work that way in 4.12.8.

[mitchdowney]

@dwvisser ok...this a bit of a shot in the dark, but I'm thinking we should initialize our v4v services after the rest of the app (player, queue, settings, etc.) finishes initializing.

Our v4vRefreshProviderWalletInfo function needs a nowPlayingItem to be available on the global.player in order to update the player state. I'm not sure moving the v4vInitialize to happen later on the PodcastsScreen will help or hurt...but I think it's worth a try.

https://github.com/podverse/podverse-rn/commit/03cea5b7d7052fbae0c0d6a5dd72afc1865f2e56

[mitchdowney]

@dwvisser v4.12.8 should now be available on iOS. Can you try the new version and let me know if the issue still pops up for you?

I'm going to close the issue for now just to move it off my plate, but if it still occurs for you, let me know here and we can reopen it.

[dwvisser]

Looks good on latest version too. I only had one incident of the issue the other day, and it was just as I was arriving at a store, and my phone was trying to get connected to their "captive portal" public Wi-Fi just as the podcast started playing.

[dwvisser]

I still see this issue, unfortunately. I'm on Verizon 4.13.0 Build 2211. Here's an additional clue: I can be listening to a V4V podcast, streaming sats, seeing the boost controls. Then it finishes, and I go pick another boost-capable podcast episode to listen to from my episode list, and it won't show the boost controls on its playback screen.

[mitchdowney]

@dwvisser sorry that's a bummer :(

If you see this issue again (the boost button goes missing when the app starts playing another V4V-enabled podcast), can you try going to More > Value for Value > Alby > and see if it correctly shows your wallet is connected?

There are three things I can think of potentially being an issue:

1) a race condition where the nowPlayingItem is not available on the Player screen at the time that the Player screen appears. If that is the case though, then I would expect that the boost button would appear if you dismiss the Player screen and then tap to show it again. Have you tried that?

2) if the Alby API rejects a "get wallet info" request with an error for some reason, then depending on the error Podverse could detect that as the wallet being disconnected. If this is the case, it could be difficult to track down (at least for me). Also, if you were to go to the More > Value for Value > Alby screen, then it should send another request to the Alby API for wallet info, and if it succeeds, then when you re-open the player, the boost controls should be there (I think).

3) Some podcasts have their V4V tags within their RSS feed, but many other podcasts have their V4V tags within the Podcast Index API. For the latter podcasts, we have to make a separate request to get the V4V tag info and load them in our Player state. If the PI API request fails for some reason, then the podcast would load in the player, but without the valueTags. Maybe we could identify if this is an issue if you reported which podcasts the issue happens with? If just one of them is RSS based (not from PI API), then that would seem to rule out this scenario.

[dwvisser]

As for option number 3, I am streaming sats and boosting to Jupiter Broadcasting feeds like Linux Unplugged and Coder Radio, as well as to Bitcoin Dad Pod.

[mitchdowney]

@dwvisser thank you. I just checked each RSS feed, and none of them contain the <podcast:value> tag in it, so they must be using Podcast Index API to host their tags. So...scenario 3 is still a potential cause of the issue.

There is another possibility related to 3) then...we make the request to PI API at the time the episode loads in the player. If you are playing downloaded episodes, and you lose internet connection, but since the episode is downloaded, it proceeds to play anyway, then the request to PI API would fail, and we won't have the V4V tags available to load in the player.

Not sure if that is the root of the issue you're seeing, but seems like there is room for some extra handling we could add for resiliency, to wait to check for the V4V tags in PI API after internet connection is restored.

rss feeds

https://feeds.fireside.fm/linuxunplugged/rss https://feeds.fireside.fm/coder/rss https://feeds.fireside.fm/bitcoindadpod/rss

[mitchdowney]

I'll look into adding a retry request for getting the valueTags from Podcast Index API if the first one fails, but I don't have a lot of confidence it will fix the issue...this is one of the hazards of using a data source outside of RSS feeds...more moving parts for things that could potentially go wrong.

[mitchdowney]

@dwvisser unfortunately this bug has eluded me for months. Without the ability to reproduce it, I'm just not sure what to do to fix. We also afaik have not received this specific bug report from other people. I'm sorry, but I'm going to unassign myself since it pretty just sits stale in my queue.

Brian of London and ChadF reported a similar sounding issue, but it was specifically that they were getting logged out of their Alby wallet in Podverse too quickly. It appears that issue may be related to an Alby login step, where he needed to select "Stay signed in for 30 days" to prevent the wallet from disconnecting every time he restarted the app. More info in this thread.

Again, I'm sorry I haven't been able to figure out a fix for this issue. I'll keep the issue open, but I may need help from other contributors to be able to make progress on it.

[clayt0nk]

3. Some podcasts have their V4V tags within their RSS feed, but many other podcasts have their V4V tags within the Podcast Index API. For the latter podcasts, we have to make a separate request to get the V4V tag info and load them in our Player state. If the PI API request fails for some reason, then the podcast would load in the player, but without the valueTags. Maybe we could identify if this is an issue if you reported which podcasts the issue happens with? If just one of them is RSS based (not from PI API), then that would seem to rule out this scenario.

I like this hypothesis, it rings true. I am in a unreliable network environment and have been seeing this on and off for many months on Android (sometimes it seems like every other episode, and then I can go weeks without seeing it once -- good luck reproducing! :-( One difference i am seeing on Android: once an episode loses v4v, it NEVER comes back as far as I can tell. Also, Android Podverse shows a lightning bolt on v4v podcast icons, and each of their individual episode icons. EXCEPT when this bug strikes, I see the lightning bolt on the podcast / show icon, but not on the episode icon. In my experience this always happens, both v4v and lightning bolt are gone forever for that episode. (I believe I have zero v4v shows added via RSS.)

[mitchdowney]

thanks @clayt0nk. I'll reassign this to me and take another look.

[clayt0nk]

Seems reproducibility is currently higher than usual, every one of the last four No Agenda episodes came down without v4v.

[mitchdowney]

@clayt0nk @dwvisser I'm still unable to reproduce the issue, so this is a shot in the dark, but after investigating this more, it appears that if the mobile app's request on app launch to connect to Alby fails for any reason, then the connection to Alby would never be re-established...except when the Alby wallet screen was visited again, or you close and restart the app.

It also looks like when the connection to Alby on launch would fail, then the lightning icons could also not appear, due to a failure to catch the network error, prior to updating the app's global state.

Anyway, to try to fix the issue, I am now re-connecting with Alby every time you make the Player screen appears, so if the connection failed when the app launched, this should retry that connection and make the boost buttons appear if it succeeds. I am also attempting re-connection when the app returns to the foreground from the background or lock screen.

I'll include these changes in 4.14.2. If you find the time to test the beta before the public release we'd really appreciate, but no pressure.

Podverse Beta sign up

[mitchdowney]

An attempted fix for this should be in 4.14.2. It should be available on Apple and Google Play within 2 days, and available on F-Droid in 7 days.

[clayt0nk]

Today's events:

1. Downloaded the most recent NA episode, it landed with episode v4v intact.
2. Started listening to the episode, sats were streaming
3. Received a notification from FDroid that updates were available, among them Podverse, and updated Podverse to 4.14.2.
4. As expected, Podverse stopped as I updated.
5. Restarted Podverse, resumed listening to NA episode where I had left off -- minus v4v. The v4v state of the episode in-progress was blown away by the update, and did not come back when I restarted the app.

Gone as in, the episode lightning bolt was also gone. Yet other episodes that I had previously downloaded (but was not listening to during the update) still had there lightning bolts.

I will update if I see anything else noteworthy as I test this release.

[mitchdowney]

@clayt0nk ok...I hadn't considered that maybe somehow the internal state / data of the app could get erased after an update. It shouldn't happen afaik, but I'm not entirely sure if F-Droid handles app updates differently than Apple and Google Play. I'll have to test this situation.

[mitchdowney]

This fix in v4.14.3 might be related to boost buttons not displaying issues https://github.com/podverse/podverse-rn/issues/2023

It should hopefully fix the primary cause of the "Alby wallet disconnects too frequently" issue.

[clayt0nk]

@clayt0nk ok...I hadn't considered that maybe somehow the internal state / data of the app could get erased after an update. It shouldn't happen afaik, but I'm not entirely sure if F-Droid handles app updates differently than Apple and Google Play. I'll have to test this situation.

Even more weird: chapters are now missing from this episode, apparently, like v4v, permanently. I have never had a problem with chapters before.

Today when I started Podverse, I got a prompt to reconnect to Alby (something I experience as quite rare) which I did, but this resulted in no change for this episodes' missing v4v functionality.

[mitchdowney]

@clayt0nk could you tell me which episode did not load chapters? We don't have control over the chapters input, so I need to rule out the possibility of an issue or incompatibility with its formatting. Also I'll need to move "chapters not loading" to a separate Github issue.

Today when I started Podverse, I got a prompt to reconnect to Alby (something I experience as quite rare) which I did, but this resulted in no change for this episodes' missing v4v functionality.

https://github.com/podverse/podverse-rn/issues/2023 hopefully will resolve exactly this problem.

[clayt0nk]

@clayt0nk could you tell me which episode did not load chapters?

That would be No Agenda episode 1604 "Janky". I listened to the last bit today and no change.

[mitchdowney]

Copying over @clayt0nk's post from #2023 over here:

v4.14.3 came down from FDroid a couple days ago. Early experience was promising, a couple old episodes of two different podcasts that had downloaded without v4v way back when, recovered their v4v capability sometime after I started playing them. Today I donwloaded NA Ep.1608, and just to be helpful, it downloaded without v4v again. I started playing and left it going for a long time, but nothing changed. I stopped the app (swiped up on Android) but audio kept playing. I tapped the app icon and the GUI spun up again, and audio stopped. Permanently. I could not get any sound out of Podverse, even though Podverse was not frozen and responded to my gestures. Rebooted the phone. Resumed playing the same broken NA episode, audio worked, still no v4v at well over an hour into the episode. I should mention immediately before listening to NA I was listening to another episode of a v4v podcast and streaming sats just fine. Switched to NA episode and it all disappeared, despite verifying somewhere in there that Podverse was still reporting being "connected" to Alby.

[mitchdowney]

it downloaded without v4v again

@clayt0nk I'm really sorry for the trouble, and thank you for the very detailed bug report. I'm really perplexed by these chronic issues the app is giving you. I have not been able to reproduce it in my local dev environment, or seen it happen recently on my phone.

This is impractical so no pressure to try it, but I would be interested to know if the same bug happens on another Android device for you.

Does the issue happen both when you are connected to WiFi, and when you are connected to data? (the v4v buttons could disappear if you don't have a solid internet connection)

I tapped the app icon and the GUI spun up again, and audio stopped. Permanently. I could not get any sound out of Podverse, even though Podverse was not frozen and responded to my gestures. Rebooted the phone. Resumed playing

Do you have the "More > Settings > Debug > Keep app open unless manually closed" setting turned on? If yes, that might be the source of the buggy app close behavior.

still no v4v at well over an hour into the episode

If the v4v does not populate when you load the episode, it likely will not detect and display them later. The v4v loading only happens when you first load an episode in the player.

Sorry I forget if I asked already. What OS are you using? Android 13, GrapheneOS, LineageOS?

[clayt0nk]

This is impractical so no pressure to try it, but I would be interested to know if the same bug happens on another Android device for you.

I have three devices, and it happens regularly on at least two of them, the third I have not used in a while.

Does the issue happen both when you are connected to WiFi, and when you are connected to data? (the v4v buttons could disappear if you don't have a solid internet connection)

Generally wifi, but in the past (not recently) I have switched to mobile data to see if that made a difference, and it seems not to.

I tapped the app icon and the GUI spun up again, and audio stopped. Permanently. I could not get any sound out of Podverse, even though Podverse was not frozen and responded to my gestures. Rebooted the phone. Resumed playing

Do you have the "More > Settings > Debug > Keep app open unless manually closed" setting turned on? If yes, that might be the source of the buggy app close behavior.

No, "keep app open" is not turned on. I have seen this thing with audio playing on after closing the app a fair number of times, it was not a one-off. I think I mentioned somewhere before that my devices (some more then others) all seem to be against the wall resource-wise when streaming sats on Podverse, although the device we are talking about here (a OnePlus 5 with 6G of RAM) has historically had the best performance.

still no v4v at well over an hour into the episode

If the v4v does not populate when you load the episode, it likely will not detect and display them later. The v4v loading only happens when you first load an episode in the player.

yeah, I figured that might be case, thus the attempted app restart.

Sorry I forget if I asked already. What OS are you using? Android 13, GrapheneOS, LineageOS?

All my devices are currently running Murena / eOS (a derivative of LineageOS) with microG replacing Google Services, currently on Android 12.

Which I have been using for a couple years now and, I have to say, generally works extremely well for a very wide range of apps including banking apps. The only downside is, like most third-party mobile OSes, it generally only has been ported to older, slower devices. My (not-so-old!!) Samsung tablet with 4G of RAM is almost unusable with Podverse streaming sats, the UI just grinds to a halt.

[mitchdowney]

This issue seems related to a myriad of performance related issues we have for Podverse for Android on some devices. We are planning to rewrite Podverse completely, with Android performance as the top concern and priority. I'm going to close this issue for now, with the expectation that a cleaner rewrite of the app will hopefully resolve bugs like this.

[clayt0nk]

What you have been doing for the past few months has improved bugginess for me considerably, it has been months since I have seen anything go seriously wrong with the v4v stuff, sats have been streaming very reliably for me (and I am a quite big data point, as I stream sats often hours per day, in an awful network environment). Yep, general performance is still a long way from "snappy", so eventual improvement in that area would be welcome. Yet Podverse is still good enough to be my only v4v podcast app. I try Breez once every few months, but they still aren't there yet, their v4v stuff doesn't work well at all in this network.

[mitchdowney]

@clayt0nk great to hear the UX is more reliable at least. But yeah in order to make it snappy we probably need to rewrite. Our React Native version is so far out-of-date it's hard to upgrade, and there's just a ton of things we'd do differently to improve performance, UX in general, and making room for new features. Thanks for the update!