[WIP] Talefish, directory based audiobook player - Page 5 - maemo.org

Active Topics

Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 5 hrs, 8 mins ago
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 9 hrs ago
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 21 hrs ago
n770 youtube video (0)
to General by nmdv - 5 days, 21 hrs ago
more...

Page 5 of 13

Thread Tools

	velox	2017-01-01 , 18:32
	Posts: 394 \| Thanked: 1,341 times \| Joined on Dec 2009	#41

Originally Posted by marmistrz

As for the concrete case: have you tried doing that in parallel? In QML it was called a WorkerScript or so iirc. Besides, I don't think you have any other way to find out the duration than to query every file unless you use tracker or any other indexer - which you don't want.

Maybe you could use some libmediainfo or so to query the data about the files and something for querying the MIME type (ignore the file if the MIME is bad). You could use a QThread so as to make it parallel. But I guess you can't do much more with QML only.

You really should ask for details on the mailing list or IRC because I don't know which libraries are on SFOS and which not.

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.

Originally Posted by marmistrz

As for the image querying, I don't get what you mean.

That's OK, I was just rambling.

Originally Posted by marmistrz

Anyway, you could simply document the quirks and say: "it's simply all that I need"
If someone needs more, they can always fork and implement it themselves and don't have to mess with the boring UI stuff.

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!

__________________
slumber: sensors enabled sleep timer for SFOS (translations/input/… appreciated if you've got some spare time)
talefish: directory based audiobook player for SFOS
nofono: ofono restart for SFOS
___
list of i486/noarch packages on openrepos (jolla tablet)

Quote & Reply |

The Following User Says Thank You to velox For This Useful Post:
dubliner

dubliner	2017-01-04 , 16:03
Posts: 171 \| Thanked: 337 times \| Joined on Jul 2010	#42

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.

Quote & Reply |

The Following User Says Thank You to dubliner For This Useful Post:
velox

marmistrz	2017-01-04 , 16:06
Posts: 3,328 \| Thanked: 4,476 times \| Joined on May 2011 @ Poland	#43

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.

__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here

Quote & Reply |

The Following 2 Users Say Thank You to marmistrz For This Useful Post:
dubliner, velox

	karlos devel	2017-01-04 , 18:08
	Posts: 137 \| Thanked: 392 times \| Joined on Mar 2013 @ Guate	#44

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

Quote & Reply |

The Following User Says Thank You to karlos devel For This Useful Post:
velox

	velox	2017-01-04 , 22:37
	Posts: 394 \| Thanked: 1,341 times \| Joined on Dec 2009	#45

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

Originally Posted by dubliner

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'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.

Originally Posted by marmistrz

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.

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!

Originally Posted by karlos devel

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

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

Quote & Reply |

The Following User Says Thank You to velox For This Useful Post:
dubliner

dubliner	2017-01-05 , 17:23
Posts: 171 \| Thanked: 337 times \| Joined on Jul 2010	#46

Originally Posted by velox

I'll at least think about how to implement something like that.

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.

Originally Posted by velox

Most of the time developing it went into how it looks

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

Quote & Reply |

The Following User Says Thank You to dubliner For This Useful Post:
velox

	velox	2017-01-06 , 01:01
	Posts: 394 \| Thanked: 1,341 times \| Joined on Dec 2009	#47

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!

Quote & Reply |

The Following 2 Users Say Thank You to velox For This Useful Post:
cy8aer, dubliner

dubliner	2017-01-06 , 09:53
Posts: 171 \| Thanked: 337 times \| Joined on Jul 2010	#48

Originally Posted by velox

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

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?

Quote & Reply |

The Following User Says Thank You to dubliner For This Useful Post:
velox

	velox	2017-01-06 , 11:29
	Posts: 394 \| Thanked: 1,341 times \| Joined on Dec 2009	#49

Originally Posted by dubliner

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?

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.

Quote & Reply |

The Following User Says Thank You to velox For This Useful Post:
dubliner

dubliner	2017-01-06 , 13:33
Posts: 171 \| Thanked: 337 times \| Joined on Jul 2010	#50

Originally Posted by velox

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?

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.