[Announce] podQast - a queue based podcast player.
 

Hi there. After three months coding I now present podQast. Available on harbour and source on https://gitlab.com/cy8aer/podqast. Have fun...

Actual Features

• Normal Podcaster Stuff
• Really play queuing
• Globally and per post configurable: Where to put a new post (Playlist, Inbox, History)?
• Automatically search for new posts
• Chaptermarks
• (if provided by feed) Select alternative audio formats
• Play single post without subscribing podcast
• Importing old Gpodder feeds
• Importing OPML
• gpodder.net search
• This thingie remembers the actual position of every post and can play it after restart
  

Planned Features

• Better finding old stuff
• Snooze mode
• Manipulation of playing tempo
• Queue: go backwards in history (sort of)
• Select Chapters to be played
• Much more

Will not work

• Start page player controls: I use QML-Mediaplayer by now

Bugs
Yeah I guess you find some. Please issue at gitlab...

Code
You wanna help? I would appreciate this, go to gitlab

Re: [Announce] podQast - a queue based podcast player.
 

Hi,
This looks pretty nice!
Because I don't have a gitlab account (yet), I'm going to write down a few things I've noticed here:

• The Startup-Wizard/Info screens are not swipeable, which was a bit confusing at first.
• Before opening anything, the cover shows "00:00:00 23:59:59"
• Gpodder search does not seem to return any results…
• Categories List seems to have a weird height. Also, entries pop in and out when scrolling – you might try to cut the dimensions with clip: true on the scrollable list.
• There's a Settings icon in the header of subscribed Podcasts: If the podcast name is too long, they intersect.
• At some places it would be nice to have a bit of "Theme.horizontalPageMargin" because of some text being directly at the side of the screen.
• Generally it looks really really good and works well. I got a bit of stuttering while playing + downloading, but I could live with that.
• Because it's mine I had to test: It seems to work well with slumber as a sleep timer.

Please don't mistake this feedback for negativity – I really like where this is going.

If with "Start page player controls" you mean controlling via lock screen, this can work by using the "MprisPlayer" QML element. I've done it here: https://github.com/jgibbon/Talefish/...layer.qml#L351

cheers!

Re: [Announce] podQast - a queue based podcast player.
 

@velox:

• Wizzard not swipable: Oups - that is page stack push without any parent. I will look at it.
• Cover at 00:00:00 - knifty. The main problem is, that I get the position information from the media player. Known Bug.
• Gpodder search: yes BluesLee (he tested it) told me about these problems before. It works. But: gpodder.net itself must work (it does most of the time). And you need to have good connectivity. I for myself do not have any problems when on Wifi but when looking at this stuff in a train...
• QueueList height: Yeah the whole qml height stuff is not as intuitive as I thought... Will try to tune.
• Options Icon and Title intersection. Known (hi BluesLee...). I for myself can live with it by now. These Icons are not designated in Sailfish design but I need these (Future: Inbox - I need an Archive-Icon to archive all...). Not sure what I can do else by now...
• Margins: ahem sloppy coding
• playing and downloading: Media player problem. When downloading it streams. And: It will play from download if it is fully downloaded and you pause/play again. But the media player is a bit ugly (look at gitlab for the rattle patch 9ff6053f... The whole downloading part needs to be tuned. But it needed time and I wanted to publish...
• Slumber as sleeper. Yes I saw slumber later. Too all: implement it in the app or use slumber?
• Mpris: Thought of it. But different api. Probably in the next version, probably other problems than with qml media player. Let's see. But: Tailfish (which uses mpris?? Yeah thats you, sorry...) lost bluetooth key functionality with Sailfish 2.0 (??). The whole multimedia stuff seems to be a bit lazy handled by Jolla (what to use and which lib is kicked on harbour).

I want to publish in blocks. So 1.1 will take some time. If you want to see what happens, look at the gitlab source (will be actualized when developing) and kick it into the JDK by your own. I decided to publish faster but I might not handle it. Except you cannot live with a bug which is grave.

And: Of course it has "bugs"...

Re: [Announce] podQast - a queue based podcast player.
 

Just for all following my development: The gitlab archive is a slave of my private gitea development. This is not as lucky as I like: I need to double all issues from gitlab to my system and you will not see every issue/milestone... stuff from my gitea system. If anyone has a trick for better gitea-gitlab interconnect please let me know...

Re: [Announce] podQast - a queue based podcast player.
 

Awesome!
Just to clarify: MprisPlayer is not a player as such (Talefish uses QML MediaPlayer as well), just "registers" a player to MPRIS, which is used for the lock screen controls with some event bindings.

Off-Topic: I thought I had successfully tested BT functionality in Talefish a while ago – I'll have to borrow a car again some time. :)

cheers!

Re: [Announce] podQast - a queue based podcast player.
 

Off topic again: I use these cheap bluetooth headsets by Anker for testing that...

Re: [Announce] podQast - a queue based podcast player.
 

Looks interesting! I might give it a shot if it ever gets mpris support (which is my main gripe with gPodder).

Re: [Announce] podQast - a queue based podcast player.
 

Hm, mpris seems not to be allowed. Coderus mentioned to compile it into the rpm but I have just python and qml and no compiled byte in the code by now. For those interested: here is the mpris stuff which is not compatible to harbour: https://gitlab.com/cy8aer/podqast/tree/mpris (it works of course).

I do not want to have this double repository problem like others have (openrepos with mpris) because of handling two master branches. So I am unhappy...

Re: [Announce] podQast - a queue based podcast player.
 

Huh, how did CuteSpot end up in the Harbour? It has mpris support.

Re: [Announce] podQast - a queue based podcast player.
 

The mpris stuff is hidden in the libspotify blob I guess. There is no mpris stuff nor any DBus stuff in the source. I have an idea how to implement it but this will take some time (if you do not have a library you need to... just dbus)

Re: [Announce] podQast - a queue based podcast player.
 

As long as I cannot get the full functionality to harbour I will publish "Forbidden Fruits" versions in OpenRepos: https://openrepos.net/content/cy8aer/podqast.

This version has rudimentary mpris support (Controls on start screen).

I have tried to do this with simple DBus but I do not know how to give functions and properties upper case names in QML DBus. And mpris defines upper case names. If there is someone who has an idea how to map qml names to upper case: please tell me how to do this.

Re: [Announce] podQast - a queue based podcast player.
 

I am asked for a roadmap. Let me show the things I have in my agenda:

• Bug fixing...
• Native MPRIS support with harbour tools. Bluetooth key handling
• Archive all in inbox. (next release)
• Set list element limit - partly in next release. This is helpful if a podcast changes internal structure and all posts are suddenly new. And it may de-stress the user...
• Opml export. Backup methods
• When downloading while playing: swap to file it downloaded
• Better download handling: Download later if it fails
• Move data to sd card
• Warning if streamed when on mobile
• Correct cover behaviour on startup
• Alter playing speed
• Possibilities to search in Inbox, History, and Favorites
• Download favorites
• Filter chaptermarks - do only play the chapters you want
• Download limit: do not download when more than xMB are already stored
• Sleep timer if we do not use slumber
• Settable refresh time
• Let already listened posts in the playlist (Pritlove wish)
• Documentation (sic!): https://gitlab.com/cy8aer/podqast/wikis/home will be the root of the docs.

Update:

• Better podcast subscribe page and subscribe handling
• Switch to alternative codec if supported by podcast

I cannot say: hey feature x will come next monday. First of all: I want to have a good podcast player for myself. Some features are not as important than for others. Some already made merge requests for other languages. Thanks for that. As other projects say: It will be ready when it is ready...

Re: [Announce] podQast - a queue based podcast player.
 

ooooooh much margins work is needed (I just look at the light themes in 3.0...)

Re: [Announce] podQast - a queue based podcast player.
 

Done with 1.3-0(ff) (mostly found another margin thingie after releasing...)

Re: [Announce] podQast - a queue based podcast player.
 

I note that podQast does not handle network drops well. In the past few days, I have lost reception twice while the app was doing something - downloading an episode in one case, adding a podcast in another - and in both cases even after the network came back I was unable to do anything that required a connection until I closed and reopened the app.

Re: [Announce] podQast - a queue based podcast player.
 

Maybe it is me coming from podcatcher, but I am not seeing the subscriptions I imported as automatically being downloaded, nor do I see a way to trigger that, the subscriptions show only the ones from the say I added them but not any new ones after they have been published. How do I trigger it to check and download new ones? I like the play feature where it keeps the time that it was played at and I can listen to another podcast in between and come back to an old one. Great work! Looking forward to the updated.

Re: [Announce] podQast - a queue based podcast player.
 

Yes this is not handled very well. But it is getting better: e.g. In version 1.7-0(ff) the downloading of queue episodes is re-initiated when the net is stable again. You can trigger a re-download by leaving the playlist and enter it again or wait 2 minutes. Then the next re-download is triggered.

Re: [Announce] podQast - a queue based podcast player.
 

I hope I understand your problems: just a quick explanation of the concept: You can globally define what happens to a new episode (preferences: global settings) top of playlist/bottom of playlist puts the episode to the playlist. If you switch on download of episodes/additional load on mobile the episodes are downloaded in the playlist. Otherwise they are streamed.

You can also configure every podcast to top/bottom playlist it's episodes: Library - longpress to podcast -> settings icon (wheel) OR press on the icon of every episode -> in the then opening overview of the podcast's episodes press the top left settings Icon (wheel).

In Inbox/history/queue: clicking on the icons move to the podcast overview (and the possibility to do settings (wheel). Clicking on the other parts of an episodes moves to the episode description. Longpress for other functionality.

So for your question - as I understand: You need to know that every podcast has it's possibility to put it's posts to the playlist - and they will be downloaded when set in preferences. If you remove any episode from the playlist (or when it is put into history after beeing played) the audio file will be deleted! In a future release I will have some smoother ways for that: Option "download favorites" - so starred episodes will be saved and the possibility to hold $count played episodes in the playlist (Pritlove wish) so that you can quickly listen/switch to just played episodes.

And in 1.7-0(ff) the download will be better handled if you have networking failures.

Another thing: Podqast is episode oriented - not podcast oriented:The episodes know where they come from and you can restore the podcast e. g. for subscribing - but the podcasts do not need to be subscribed. It is possible to just put one episode of a podcast into the playlist: discover any podcast, look at the full list (yes the bigger icon in the podcast overview gets you to the full list) longpress one episode and choose what should be done with it. I am not happy with the podcast overview/subscribe page (first/last entry is nuts with the full list icon). It would be better to have more information about the podcast there (url to the web page, format and stuff like that).

Sorry the writing of a useful manual (at gitlab) is on my queue but not very advanced.

Re: [Announce] podQast - a queue based podcast player.
 

Version 1.7-0(ff): because it took too much time to implement everything I now have an "experimental" flag in preferences. If switched on you can look at some stuff which is not fully implemented but may be helpful.

In 1.7 with experimental switched on you will have an export page in discover. There you can make a backup. This will create a tarball at ~nemo/podqast-$(date).tar.tz. But actual I do not have a restore functionality. What can you do with this backup tarball?

The tarball includes the icons and the data structure at the point of backup. No audio files.

Manually restore:

Close podqast...

If you then restart podqast 1.7up will then re-download all audio stuff in the playlist and you will be at the point of backup.

Re: [Announce] podQast - a queue based podcast player.
 

Ah and only new episodes after subscribing will be automatically handled. All posts at the point of subscription must be handled manually. Probably we can make a preferences parameter for put to playlist/downloading the last $count episodes after subscription. What do you think?

Re: [Announce] podQast - a queue based podcast player.
 

just some feedback. i read that you made the application for yourself so maybe ill hit a brick wall. regardless:

• application takes an age to load items in the library if podcasts are updating
• in library i personally dont like how both history and favourites stay on top and podcasts scroll underneath them. maybe an option to turn it off in the settings?
• same for inbox i dont like visually how all the podcasts are listed horizontally across the top, i realise it might be useful if you have hundreds of podcasts but i think its too cluttered and ugly. would be nice for an option to turn it off
• in inbox think the folder for archive looks out of place and might be better as a pull down
• regarding notifications, insstead of a list on sailfish homepage, the newest found podcast just writes over the last one leaving only one result. seems pointless therefore to have it as a notification

other than those i really appreciate the application and your efforts. i use it a lot now. i just dont think its as clean a a nice jolla application, including gPodder.

Thanks again, Regards.

Re: [Announce] podQast - a queue based podcast player.
 

I just tested podQast for the first time today and it's terrific.

Just wondering, would it be possible to add functionality to the Bluetooth keys? They work fine with Talefish. In the car it's really helpful to be able to pause and skip once in a while.

Anyway, please keep it up!

Re: [Announce] podQast - a queue based podcast player.
 

That's not for harbour, though, because I am using the Sailfish.Media 1.0 import.
Anyway, here's how to do it: https://github.com/jgibbon/Talefish/...layer.qml#L413

cheers

Re: [Announce] podQast - a queue based podcast player.
 

Actually, I got podQast from Openrepos, anyway. @cy8aer, would it be very difficult to have a slightly more feature-rich version of podQast out on Openrepos for a while until MPRIS has been successfully integrated with the harbour tools? I am just asking because it's a little uncomfortable stopping the car whenever I notice I am not really interested in a particular episode of a podcast (or alternatively, suffer listening for a while ;) ).

Re: [Announce] podQast - a queue based podcast player.
 

Ok, version 1.9-0ff will have bluetooth - But....

... it does not work with every device. I tested it with an Anker Soundbud and with my car's hands free kit.

JollaC: Does not work (with Talefish neither!!!). Jolla1 does work. Because I develop with the C most of the time I did not implement it because it simply did not work.

Those who have no problems with Talefish will probably lucky with podqast 1.9 up (openrepos) too. But do not expect too much support for it until the bluetooth support is more stable for all devices. Will be out later this weekend because I would rather implement the help/documentation system - and that is not ready today.

But it is already in the gitlab-repository in the ff branch (for the impatient who can build their own packages).

[update] 1.9-0ff released

Re: [Announce] podQast - a queue based podcast player.
 

Wow, you are great!!! Thank you so much for adding that feature so incredibly quickly. Much obliged! :)

Re: [Announce] podQast - a queue based podcast player.
 

yeah @cy8aer is a faster dev, also @cy8aer is created an unique AboutPage design = )

Re: [Announce] podQast - a queue based podcast player.
 

Where does Sailfish.Media 1.0 come from? Is this really a Jolla library?

Who is responsive for the code and how does bug reporting work for this library? I am asking because it does not work on the JollaC but on the Jolla1. On which other devices does it work?

Re: [Announce] podQast - a queue based podcast player.
 

So, I got to test the bluetooth keys today and everything is working like a charm. Again, thank you so much cy8aer!!!

Would you mind hearing about some thoughts? Not sure if any of them are useful. Well, I thought it might be nice if the "status report" (i.e. "refreshing ...") were somewhere in the visible part of the screen. That way one wouldn't have to swipe to find out what's happening.

Okay now, here is a crazy thought. :cool: Would it possibly be a useful feature to be able to manually add local audio files to the playlist? I realize that would create a hybrid functionality, sort of a podQfish or taleQast approach. :D

Oh, there is one tiny thing I noticed. With the Linux Action News podcast there doesn't seem to be a logo. Also, it seems like refreshing that particular podcast took awfully long. Not sure, though, if you wanted to hear about that. After all, it's just one podcast.

Re: [Announce] podQast - a queue based podcast player.
 

The refreshing is - rudimentary - shown with the blinking pulley menu. There it is shown what is refreshing. Ok it is not very perfect. It's the same with storeman - whith the updating of the repos. Nobody looks there. Does Sailfish/Qt have any suggestions on how such a status should look like? I already scruple with the icons in inbox and podcast post list - which are not working as the UI definition expects.

Local audio files to the playlist. Probably possible. I put it on my internal queue.

Not showing icons: That is one point I am not happy with. Maybe you found out that 1.9 has a help menu which points to gitlab wiki pages. My main work last week was to write documentation.

For debugging there is e. g. https://gitlab.com/cy8aer/podqast/wikis/developer-debug - feed.image.href must work otherwise the icon is not shown. I did not expect that a large part of the development would be not well formed feeds...

Re: [Announce] podQast - a queue based podcast player.
 

Yeah, it seems to be a "internal" Jolla library. User "hedwig" did encounter the same bug in Talefish which I could reproduce in january. The workaround then was to downgrade the buggy BlueZ 5 to BlueZ 4 – so it's not really a bug in Sailfish.Media, but in the BT stack.

Talefish post

Workaround source on TJC

A word of warning: I have not tested it since and there's a comment on TJC that it apparently broke BT on 2.1.4.14

cheers!

Re: [Announce] podQast - a queue based podcast player.
 

So I'm still a little bit confused about how this works. I've been downloading podcasts by long-pressing them and hitting the little down arrow, which seems to add them to the queue (is there a better way to do this? It's not very clear what the icons mean.) Usually, when I get to the end of one the next one in the list starts playing; but sometimes it doesn't, and I'm not sure why. Half the time it doesn't, if I open the podcast in question it shows the playback bar all the way at the end of the episode, but if I drag it back to the beginning it will play.

Re: [Announce] podQast - a queue based podcast player.
 

First of all: https://gitlab.com/cy8aer/podqast/wikis/the-manual - and with 1.9 you have a context sensitive help (sub pulley menu) which points to the pages in this wiki. You know it: documentation is the last thing... It shouldn't. Look at the main concept there. The documentation is not complete - I am still writing on it: podcast subscribe page is missing, also the whole discover stuff. Needs a bit time, sorry.

If a podcast post in the playlist ends playing it should be removed from the playlist, put to the history and reset to position 00:00:00. The hanging effect you have is interesting and needs investigation.

Re: [Announce] podQast - a queue based podcast player.
 

I cannot seem to figure out how to remove a podcast from the playlist.

Also, sometimes certain podcast episodes do not seem to be downloaded. I have yet to figure out a pattern. Losing Internet connectivity might play a role perhaps?

Re: [Announce] podQast - a queue based podcast player.
 

Put the podcast post to the archive (longpress-menu file symbol) and it is moved away from the playlist (to the history - everything ends in the history). Or (just to mention): play the post to the very end. After playing it is also put to the history.

If a post is not downloaded it should be downloaded again some time later (minute timer) when the internet connection is stable again. What might help: Switch to another page and back to playlist (then the re-download is triggered outside the timer loop). It also should try to re-download after restarting.

Yes this is not as good as you (and me) want to have it: There is some handling missing for hanging http downloads. If someone has an idea how to make it better with the used urllib this would help.

Re: [Announce] podQast - a queue based podcast player.
 

The archive button was rather confusing for me; I spent a long time looking for some sort of trash can icon for deleting listened podcasts (due to previously mentioned bug where listening to the end doesn't always trigger the delete). Eventually figured out that the folder icon, which I assumed would be "open folder containing this file", actually deletes it.

Re: [Announce] podQast - a queue based podcast player.
 

The main problem for me is creating new icons. I tried to use standard icons (see: https://sailfishos.org/develop/docs/jolla-ambient/) and learned: saving makes the whole thing not intuitive... Sorry.

But the documentation for this is just a bottom help menu away (since 1.9-x)

Re: [Announce] podQast - a queue based podcast player.
 

Again, thanks so much for your work, cy8aer.

To be quite honest, I haven't quite figured out the purpose of the archive. Is it just a record of all podcast episodes seen (and listened to), so this data can be used, firstly, when displaying the library, and secondly, when deciding which podcast episodes have been played (i.e. to avoid downloading them again).

"Moving" an episode to the archive automatically causes this episode's audio file being deleted, right? In that case, how about just switching the icon from "folder" to "icon-m-delete"?

Re: [Announce] podQast - a queue based podcast player.
 

I do not delete the post. The audio handling is independent from the existing of the post. So an archive icon is IMHO better.

Hm, there is one implementation thingie missing: the favorites. Making a post a favorite (star) should make the audio persistant - which means audio is downloaded and presented in a defined folder in the system e.g. ~/podqast/favorites.

Dynamically deleting audio when leaving the playlist makes sense for the system disk point of view: if you have a 16GB device it would fillup the disk with audio. There is also a "feature" missing which downloads new audio if less than X disk space is used. Otherwise it would be downloaded if played posts disappear and then less than X disk space is used.

I am also thinking of leaving the last x posts in the playlist for jumping back to leave the audio on disk for some time. But all this is not well thought yet.

And the history page shows all posts you had in inbox or playlist - so it is a history where you can get the posts to playlist back again. But to avoid a download you would need the not now implemented favorite.

Re: [Announce] podQast - a queue based podcast player.
 

Thanks for your detailed response, cy8aer. I appreciate it.

I completely agree with you about the limited space on the device. Deleting the episode after it's been played is a prudent precaution, which I am quite happy about.

Some ideas about the GUI. Wouldn't it be parsimonious to combine the "inbox" and the "library" into one dialogue? The available and the downloaded episodes could be numbers on top of the podcast logo, i.e. 2/5 -> five available, two of those already downloaded to the playlist. Then, you'd only have one place for all the information. I have to admit I was at first confused about the "inbox". After all, I expected everything coming in should appear on the playlist (at least for my use case).

If the main aspect of the favourites is to "download" them into a different folder, how about calling that functionality "permanent download" or just "sticky"? By the way, I like the idea of a separate folder. That makes it easier to find the episode for transfer.

One more question about the archive. If the episode is removed from the feed, will it still remain in the archive? Wouldn't it be a good idea to completely remove it then, unless is has been downloaded (as a favourite or just lingering in the playlist)? Again, saving space might be an argument in favour of this. Why keep outdated data? Also, if you delete a podcast, the relating data should be removed. I have some trouble getting episodes automatically downloaded with on podcast (I must have limited to number of downloads to 2 when a whole avalanche of episodes appeared on the feed - ever since then PodQast has been refusing to download any episodes from that podcast automagically). So, I thought deleting the podcast from the library and then discovering it again might solve the problem. But everything just came back as before.