Podbird reignited

PhoenixLandPirat

On Telegram someone said that they'd put some time and effort in, if it was hosted on github or gitlab, if there hadn't been any update, for a very long time, I wouldn't mind the idea of rehosting it, but I'm hesident to rehost the code if the original people are still wanting to work on it.

It'd feel like stealing there project, but if its not them working on it, and people would much prefer to host on github or gitlab, then it'd be good if we could get in contact with either Michael Sheldon, or Nekhelesh Ramananthan, and see what they think.

They might give us the go ahead to just rehost and still use the name and logo, etc, etc, or they may require us to rename the app since it would be hosted by different people?

I think it'd be wise to get in contact with them before we do any heavy lifting if that's the road we wish to take.

theare27

@PhoenixLandPirat
Of course the ideal would be for the current maintainers to push on with the project & fix the bugs, but if they've lost interest they should let the community know so that someone else can take it over or so that it can be forked

For me, and I suspect many others, playing podcasts is an important use case for my device. If development is paused on this and there is no other alternative application available then that's a bad position for UT as a whole to be in

PhoenixLandPirat

@theare27 obviously we would all like the project to solder on, but as a community, we have to do it in a way which respects those who had previously made the code.

We have the right to fork the code, it's GPL, right, but just because we have the right to do so, doesn't mean its the first thing we should do, it'd be easier to just fork it and work, but we should contact the two originators first.

I think they'd be happy to see a fork on github, especially if they're not working on it, but I think they'd probably want to know before it happens, even just a "Hi, we've got a few people who'd like to work on podbird, are you still working on it? and would we be able to put the code on github?" kinda thing.

I'm not saying that we have to force people who dont want to work or dont have time to work on the project, work on it, just let them into the loop, so they know what we're doing, and see if they've got plans, you know.

AppLee

@PhoenixLandPirat
Yes that's the spirit.

If you don't have an email or another to directly contact the original maintainer, I'd suggest to open an issue in their repository asking if they are still interested in the project or how they prefer to fork.
That's what I did for another unmaintained app on the open-store.

The maintainer was very pleased to see someone keeping the app alive and useful to others.
My contribution was just rehosting, integrating clickable and building for 16.04

geekvine

I'll be happy to help. Ive been working on a forked version of podbird on and off as a personal project. I do have the sqme concern as another commenter regarding switxhing to git (bzr plugin or not).

theare27

@geekvine Just out of interest, does your work give you any insights on what's causing the queue to be lost when the app is closed?

geekvine

@theare27 I listen to podcasts 40 hours a week so I never close it but i can look into it.

theare27

@geekvine Restarting the phone also has the same affect for me
It's not that I'm closing the app on a whim, I often end up having to reboot the phone at least once a day

dobey

@alan_g said in Podbird reignited:

Is that because he has no current interest in the project and can't be bothered?

It's more that he hasn't the time to do feature development right now, but is happy to merge things and upload new releases (as he recently did, given the last update in the store is from a month ago).

geekvine

@dobey thanks for the info. I'm gonna try to get in touch with him since there seems to be some interest in helping out.

Giiba

I always figured the queue being lost was a feature that was missing. If it is a bug that can be resolved that would make Podbird complete as far as I am concerned.

theare27

@Giiba I've been poking around the code a bit this afternoon. I'm a web developer not an OS / native apps guy so I could be way off, but it certainly looked to me as if clearQueue (which deletes everything from the Queue table) is being called when the app exits

If that's the case, I wonder if that could be tweaked so that it could be controlled from the conf file

a clearQueueOnExit boolean flag

But like I said, I could be misunderstanding the code

Giiba

@theare27 better than I!

I once poked around the code and all of it meant nothing to me.

theare27

Podcasts.clearQueue() is called as part of Component.onDestruction which I'm assuming is on app closure

jezek

@theare27 try to comment it out, what happens (or not happens)

CiberSheep

@theare27 said in Podbird reignited:

Podcasts.clearQueue() is called as part of Component.onDestruction which I'm assuming is on app closure

Pretty sure that is to clear the queue of episodes that you can pile.

The position of the episode is stored in the db

Position (even if it looks to jump) is stored and retrieved, so I suspect that might be a change in the Media-hub. We started experimenting position lost when moved to Xenial
https://paste.ubuntu.com/p/4VqqDpG64c/

arubislander

@jezek
Commenting it out keeps the entries in the Queue database, but extra code is needed in the Component.onCompleted to populate the playlist with the entries:

        db.transaction(function(tx) {
            // Rebuild queue in order
            var rs = tx.executeSql("SELECT url FROM Queue ORDER BY ind ASC")

            for (var i=0; i<rs.rows.length; i++) {
                player.playlist.addItem(rs.rows.item(i).url)
            }
        })

TartanSpartan

@TartanSpartan said in Podbird reignited:

I believe the progression from the Vivid to the Xenial build introduced a regression wherein you used to be able to have your place in an episode automatically saved when the app closed, but now no longer. Shall test this theory on my new M10 (with Vivid) later.

Definitively confirmed.

theare27

@TartanSpartan
Not saying it's not a problem external to the application - could well be

But when the app exits the Queue table in the app's SQLite database is cleared - everything is deleted from that table

Data in other tables - like the Podcast one that holds the subscriptions persist so it would certainly seem like clearing out the queue on app exit is a deliberate action that's triggered somewhere

theare27

@arubislander And there's also no way to get back to the "now playing" screen after the app is restated without starting to play a file - which in itself would wipe the previous queue

Would it be possible to add a "Now Playing" entry to the hamburger menu so that one can get back to where they were

Like you say, stopping the queue from being wiped out is only half the problem