velox | # 41 | 2017-01-01, 18:32 | Report

It's been a while, but I think I tried workers but they couldn't access the qml player objects or something like that. I don't think I tried QThread (Thanks!). Also, I'm a bit of a dumb nut when it comes to C++ (even integration), which is why I prefer to write QML as well. You're right: Using Tracker defeats the purpose of the player entirely.

That's OK, I was just rambling.

Since this really were my first ugly attempts at SFOS and QML I'm a bit embarassed about it (quirks: almost all of it) so I decided I won't clean the source and publish it before there's a chance someone would even be inclined to help, because I'd rather spend time with my dearest… chicken→egg problem, I guess. But since there still seems to be ongoing interest in (or lack of alternatives to) Talefish, I think I'll resume fiddling with it starting in the next months, if things go according to plan. Maybe I'll even abandon my slightly hacked tolino device for a bit and listen to some audio books again. Thanks, all, for the motivation!

dubliner | # 42 | 2017-01-04, 16:03 | Report

What do you mean "seems to be ongoing interest in Talefish"? It's truly the best software for the task!

It's slowly dawning on me how the directory based approach works. I have to admit it's quite ingenious for the purpose of playing separate audio books.

But wouldn't the traditional approach of populating a playlist be more versatile? Scenario: You'd have a dialogue similar to the present one allowing you to choose a file or a directory (sorted according to various criteria: name/mtime). The selection is, then, transferred into some array along with markings to represent the current playback position. This way files could be enqueued into the playlist allowing Talefish to play more than one book (or a multitude of podcasts) during one long trip without having to fumble with the cell phone.

I do realise that this would require major reconstruction within the code. And I am rather ashamed to admit that I don't understand anything about QML or JS. So, I can't be of much help.

marmistrz | # 43 | 2017-01-04, 16:06 | Report

velox: you can make a neat trick as for the file discovery. I mean: a .pragma library which is a wrapper for the backends. Pros:
- Users can choose the other of the backends, when the other is malfunctioning.
- You can modify the code by parts and check if nothing breaks.
- If you decide that e.g. libmediainfo has it's quirks, you can easily add another backend based on whatever.

karlos devel | # 44 | 2017-01-04, 18:08 | Report

i just wanna say that TALEFISH it a good UI app.

velox | # 45 | 2017-01-04, 22:37 | Report

Whoa, ok, it seems I underestimated that "ongoing interest". You folks are great!

I'll at least think about how to implement something like that. Seems like a useful thing to do – but if it doesn't work nicely, I most likely won't include it since it kind of breaks the usage paradigm I had in mind. Or I might do it as a hidden easter egg or something. An enqueue function that breaks the "I'll remember how far you played this after you open something different" function should be no huge problem.

I'd have to be able to simply include libmediainfo (or something similar) first (I'll have to find the time to learn a bit more stuff), but really nice idea! Thank you!

Thank you so much! Most of the time developing it went into how it looks, glad you like it.

dubliner | # 46 | 2017-01-05, 17:23 | Report

Disclaimer: I have no idea if this is of any help. If it's stupid, please just disregard it. ;-)

How about using two separate fields? For example:

currentPosition TIME (with each file)
currentlyActive INTEGER (for file ID)

This way Talefish could save all the positions within each separate file while at the same time having the means to jump to the last file played. In fact, I'd probably put the "last file played" field outside of that table.

That really paid off! It looks just wonderful!!! I keeps making me smile when I look at that old tape reel. Kudos!!!

velox | # 47 | 2017-01-06, 01:01 | Report

I've pushed build four (0.0-4) to openrepos a few minutes ago.

Changes:
- Display file/folder names on Lock Screen
- Simple enqueue function (will not save progress for reopening that directory)
- Show directory name in Playlist view


Turns out I just had to wait a bit (didn't find a good enough ready event so it's a simple timer – shame on me) before populating the lock screen texts or MPRIS would just get angry and ignore those infos. It's still a bit buggy and will remove the directory name when (only) tracks change – but that's something I hope to fix in another update. This one only took a year, so you can really get your hopes up for that ("soon", you know the drill).

Also, I went the (really) easy way for enqueuing files as you can see in the change log. You'll have to enable it in the options.

Enjoy!

dubliner | # 48 | 2017-01-06, 09:53 | Report

You're amazing! Thanks a million, velox! I'll be testing it today.

BTW, I noticed that sometimes Talefish freezes while importing a directory. This cannot be reproduced, unfortunately (albeit, it may freeze at a different position on second try). After freezing and rebooting, Talefish will just freeze again until the ~/.local/share/Talefish directory has been removed. I noticed this yesterday and, again, today after installing the new version.
Is there any way that could help debugging this phenomenon?

velox | # 49 | 2017-01-06, 11:29 | Report

Hm, one way to go about that would be for me to put debug output in every little corner of the script and provide you with that version. You'd have to open (/usr/bin/)Talefish from Fingerterm then until the Error is found. Would that be something you'd be willing to do? If yes then please PM me your mail address and I'll try to prepare that version and send it to you tonight.

dubliner | # 50 | 2017-01-06, 13:33 | Report

I'm curious, wouldn't it be even more effective to put these debug marker in permanently into the release version and only activate them with a command line option (e.g. -debug)? All of us could try, then, whenever we come across a more "stubborn" audio book.