Audiobooks.bundle
Audiobooks.bundle copied to clipboard
macr0dev
search by audible code?
Hi, would it be possible to tag the MP3 files with Audible's own "codes", and then have the scraper do a search using that code if nothing else matches? i.e.: the "B00DDVSD34" part from https://www.audible.com/pd/Nonfiction/The-Great-Ideas-of-Philosophy-2nd-Edition-Audiobook/B00DDVSD34
I added support for this on my fork. https://github.com/dethrophes/Audiobooks.bundle/commit/6d55e12ecaf9cbc63a125f9752e92e897331cbfe
I've added this to the master branch as well. Although if you have issues locating any books through the search I've like to take a look at that.
Adding the audible ID to the tags and/or folder names sounds tedious. If I can write in some exceptions for something that would probably preferable.
It depends on the problem. Mostly the problem is that my title doesn't cleanly match the on audible. So I would have to rename the titles anyway. What I found to be more of a problem is the files where there are multiple versions of a book on audible and I want to match to a specific one. Anyway it's something I use quiet a bit, in all my libs. you can search for movied with the imdb number, or at least you used to be able to. Other agents also support this.
I think it also has to do with how many files you have, i figured out a long time ago that with a lib the size of mine, I'll never be able to tweak the agents to parse it all. It's easier and makes more sense to curate the lib.
Fair enough. I'm going to rework the section that "removes any text that's in brackets and parens" so that the manual search will work if you put in audible-xxxxxx. Right now it only seems to work if it's in the title of the first track. I'm sure it may work in a few other ways too, but for sure it's not working if you just paste it into the manual search.
You might want to refork after that. Or pick of a few of the tweaks that I've added in the last few days. Most notably a tweak that splits multiple narrators into multiple tags. Previously, they all loaded into the same tag.
Actually one of my versions already splits the narrators.
I'll see about the rest.
Am 24.07.2017 00:00 schrieb "macr0dev" [email protected]:
Fair enough. I'm going to rework the section that "removes any text that's in brackets and parens" so that the manual search will work if you put in audible-xxxxxx. Right now it only seems to work if it's in the title of the first track. I'm sure it may work in a few other ways too, but for sure it's not working if you just paste it into the manual search.
You might want to refork after that. Or pick of a few of the tweaks that I've added in the last few days. Most notably a tweak that splits multiple narrators into multiple tags. Previously, they all loaded into the same tag.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-317285329, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA80TRwiZ5ouoj0N30kut0j6Hi3Pi-ks5sQ8KZgaJpZM4OEb9_ .
Is this implemented in the current release? I can't figure it out.
Adding the audible ID to the tags and/or folder names sounds tedious.
As someone with an Audible library, Audible audiobooks have the code as their filename when downloaded. It's already there, waiting to be scraped. Here's an example filename: B00IZOP8CI_LC_64_22050_Stereo.aax. Scraping the code out of the filename would be the easiest method by far.
I just discovered this plugin, so forgive me if I misunderstood something. From my perspective, requiring the Album tag to contain the Title is considerably tedious. Audible files are already tagged, and the Album tag is set to the author. I'd have to update the Album tag of every book for this plugin to work.
I'm aware audiobooks can come in parts, and I suppose that is why you've opted to detect the Album as the title. But, why are audiobooks sometimes in parts? Imo if you have a book in parts, you should just combine them into one file.
Plex doesn't support aax files. so you will have to convert them to m4b/mp3 to have them in plex.
The filename naming convention is also different depending on how you download the files, they don't all include the audibleid in the filename.
HAving books as one file doesn't work for everybody. Having a 30+ hour m4b file isn't supported by many clients. Also if the book is in mp3, which doesn't support chapter info then it is very hard to navigate the book. As such the normal approach is to have the book split. either by chapter(mp3) or into approx 6 hour chunks(m4b).
On Tue, Nov 7, 2017 at 5:24 AM, Aelius [email protected] wrote:
Is this implemented in the current release? I can't figure it out.
Adding the audible ID to the tags and/or folder names sounds tedious.
Not exactly. Audible audiobooks have the code as their filename when downloaded. It's already there, waiting to be scraped. Here's an example filename: B00IZOP8CI_LC_64_22050_Stereo.aax. Scraping the code out of the filename would be the easiest method by far.
I just discovered this plugin, so forgive me if I misunderstood something. From my perspective, requiring the Album tag to contain the Title is considerably tedious. Audible files are already tagged, and the Album tag is set to the author. I'd have to update the Album tag of every book for this plugin to work.
I'm aware audiobooks can come in parts, and I suppose that is why you've opted to detect the Album as the title. But, why are audiobooks sometimes in parts? Imo if you have a book in parts, you should just combine them into one file.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342371903, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA8x5KnEfYFZC-bLnjJ9xXnnUuT5aFks5sz9uNgaJpZM4OEb9_ .
I just discovered this plugin, so forgive me if I misunderstood something. From my perspective, requiring the Album tag to contain the Title is considerably tedious.
This metadata agent is designed to piggy back off the built in functions on Plex's music and album features. Because their music libraries group tracks by album, it's necessary to have these tags present. This is not something solely related to identifying the book but is a necessity for Plex's internal organizational structure.
Plex doesn't support aax files
I'm aware. They're encrypted and require a conversion. I convert to mka, a format which happens to support chapters, thereby solving navigation issues.
Having a 30+ hour m4b file isn't supported by many clients.
Thank you for explaining, but the answer just makes me wonder: why not use a better client? If your client can't handle large files, it must be pretty dated, or poorly written...
Because their music libraries group tracks by album, it's necessary to have these tags present.
The tags are present. It turns out I misread what the tags where, though. Here's a sample audiobook, with metadata as reported by ffmpeg.
genre : Audiobook
title : The Subtle Knife: His Dark Materials, Book 2 (Unabridged)
artist : Philip Pullman
album_artist : Philip Pullman
album : The Subtle Knife: His Dark Materials, Book 2 (Unabridged)
comment : In this stunning sequel to The Golden Compass, the intrepid Lyra finds herself in a shimmering, haunted otherworld, Cittagazze, where soul-eating Specters stalk the streets....
copyright : ©1997 Philip Pullman; (P)Random House, Inc., Listening Library, A Division Of Random House, Inc.
date : 2003
Maybe the issue is your plugin or plex just aren't getting the tags out of the mka format? Where do we stand on detecting the audible code in the filename?
Am 07.11.2017 16:19 schrieb "Aelius" [email protected]:
Plex doesn't support aax files
I'm aware. They're encrypted and require a conversion. I convert to mka, a format which happens to support chapters, thereby solving navigation issues.
Again this is specifically you. Most people have a mix of mp3 and m4b. There is no real Interest in reducing the comparability of the agent.
Having a 30+ hour m4b file isn't supported by many clients.
Thank you for explaining, but the answer just makes me wonder: why not use a better client? If your client can't handle large files, it must be pretty dated, or poorly written...
There are only a limited number of clients that support chapters. Especially hardware mp3devices. Or cars etc... you make too many assumption as to the use cases. Additionally split files can be much better for remote sync. Even audible splits the wax files in certain configs
Because their music libraries group tracks by album, it's necessary to have these tags present.
The tags are present. It turns out I misread what the tags where, though. Here's a sample audiobook, with metadata as reported by ffmpeg.
genre : Audiobook
title : The Subtle Knife: His Dark Materials, Book 2 (Unabridged)
artist : Philip Pullman
album_artist : Philip Pullman
album : The Subtle Knife: His Dark Materials, Book 2 (Unabridged)
comment : In this stunning sequel to The Golden Compass,
the intrepid Lyra finds herself in a shimmering, haunted otherworld, Cittagazze, where soul-eating Specters stalk the streets.... copyright : ©1997 Philip Pullman; (P)Random House, Inc., Listening Library, A Division Of Random House, Inc. date : 2003
Maybe the issue is your plugin or plex just aren't getting the tags out of the mka format? Where do we stand on detecting the audible code in the filename?
M4a/m4b files work I use them myself. What isn't working for you, exactly? Anyway t sounds like this is an unrelated issue.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342514926, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA85yx3iaPmkYAAwcyGPpSJSLlddAXks5s0HT3gaJpZM4OEb9_ .
The tags are present. It turns out I misread what the tags where, though. Here's a sample audiobook, with metadata as reported by ffmpeg.
That's all fine and good that ffmpeg reports them. If Plex doesn't see them, they might as well not be there.
Maybe the issue is your plugin or plex just aren't getting the tags out of the mka format?
The metadata agent doesn't interact with the files. That's the scanners job. The agent takes whatever Plex will give it.
Where do we stand on detecting the audible code in the filename?
It's not a priority. If your tags are well maintained and match closely enough to what's on audible's website it should match.
Confirmed, plex just isn't getting tags out of mka. I'll have to report this to plex.
Unfortunately, ffmpeg doesn't appear to support m4b, so I can't realistically use that as a target format for my library. m4a doesn't support chapters, and mp4 isn't detected as "music" by plex.
MKA remains the best solution.
In the meantime, if the topical feature is not implemented, and the idea is still on the table, shouldn't this issue be open? For what it's worth, getting information from the filename would make sense as a feature in your plugin- this "tedious" method is consistent with how plex normally operates. It's an abberation to not have this in some form.
m4b is an m4a file with chapter data more or less. just use ffmpeg to create the m4a file then rename it to m4b, then use mp4chaps to add the chapter data.
On Tue, Nov 7, 2017 at 5:54 PM, Aelius [email protected] wrote:
Confirmed, plex just isn't getting tags out of mka. I'll have to report this to plex.
Unfortunately, ffmpeg doesn't appear to support m4b, so I can't realistically use that as a target format for my library. m4a doesn't support chapters, and mp4 isn't detected as "music" by plex.
MKA remains the best solution.
In the meantime, if the topical feature is not implemented, and the idea is still on the table, shouldn't this issue be open? For what it's worth, getting information from the filename would make sense as a feature in your plugin- this "tedious" method is consistent with how plex normally operates. It's an abberation to not have this in some form.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342547790, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA87TYByXZyqIfzj5afTNFET9H1gOjks5s0ItFgaJpZM4OEb9_ .
In the meantime, if the topical feature is not implemented, and the idea is still on the table, shouldn't this issue be open? For what it's worth, getting information from the filename would make sense as a feature in your plugin- this "tedious" method is consistent with how plex normally operates. It's an abberation to not have this in some form.
All I can say is that it's not as simple as you're laying it out. This is a metadata plugin. Plex hands off certain data to agent and it can use that data to attempt to provide a match and provide details back. If an album has multiple tracks, it doesn't pass each track. I'm sorry that you find Plex's method of grouping tracks into albums "tedious." But this is not the place to address that problem.
And considering that this isn't done with ANY OTHER music feature inside Plex, it's not an "aberration." This agent works exactly like Plex expects it do.
I'm sorry that you're having trouble getting things to work like you want. But hundreds of others are not having any problem. Which means that making code changes to do something the way that you want is not the answer.
And frankly, you're just being kind of rude about something that people are spending their free time doing for the good of the community.
I'm sorry that you find Plex's method of grouping tracks into albums "tedious."
I was quoting your earlier use of "tedious"- in which you referred to renaming files. Which is the method one must use in plex's main function: video. I don't find it tedious, but I continue to quote you since I found it strikingly odd that your initial dismissal of the idea is based on something one routinely does for plex.
And frankly, you're just being kind of rude
Sorry you feel that way. I think you've been misunderstanding a few points throughout this discussion. Likewise, the feeling I get from you is you're "brushing me off" this entire time, which might have contributed to my tone. Your responses seem minimal to the point that you're annoyed I'm even bringing up this request. This issue being closed contributes to that feeling.
The issue was closed back in July because 1) it was unnecessary and 2) it goes against the convention that is considered pretty standard for the vast majority of audio tracks. It has no bearing on this conversation.
I'm not sure how you're feeling brushed off though. Both myself and another developer have been explaining to you how this all works and making suggestions on what your problem may be. If I wanted to bush you off, I'd just not respond.
Actually it was closed because it was working... I haven't used it in a while though.
Basically the syntax was/is to add [audible-
This may work better on my branch, https://github.com/dethrophes/Audiobooks.bundle, let me know if it doesn't work.
There have been requests to change how this works, but I haven't had a chance yet as it is a bit tricky given the division of labour between the agent and the scanner. And the search works a lot better for me since the special character handling in search terms has been improved.
On Tue, Nov 7, 2017 at 6:36 PM, macr0dev [email protected] wrote:
The issue was closed back in July because 1) it was unnecessary and 2) it goes against the convention that is considered pretty standard for the vast majority of audio tracks. It has no bearing on this conversation.
I'm not sure how you're feeling brushed off though. Both myself and another developer have been explaining to you how this all works and making suggestions on what your problem may be. If I wanted to bush you off, I'd just not respond.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342561366, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA84mUmt0JVap-A138famoRrMfP5USks5s0JUkgaJpZM4OEb9_ .
The issue was closed back in July because 1) it was unnecessary and 2) it goes against the convention that is considered pretty standard for the vast majority of audio tracks.
Conventionally music programs rely on tags, yes. But I'm considering the functionality of plex on the whole: a database for general media.
In this subcontext of plex, we have a reliable, consistent, and exact database of IDs (audible). This may not be strictly necessary, but it certainly makes sense within this ecosystem and adds absolute precision to matching. I think that's valuable and topical. In the process of manually matching my audiobooks, I've already found a couple of books that have multiple audible releases, and I've only imported 7 books so far!
And yes, thank both of you for your explanations and help thus far. Thank you for your work on this agent. Even with the manual matching I have to do (*) , the functionality provided is great.
(*) Thanks for the suggestion about m4b @dethrophes but I will not be taking that approach; much prefer to see proper mka support implemented in plex.
Actually it was closed because it was working... I haven't used it in a while though.
Basically the syntax was/is to add [audible-
] to the Album name.
Ah, album name. That would explain why I couldn't get it to work, as I was hoping to handle this on the file level. While I'm happy to change tags for music files (music is generally its own disorganized beast), in the case of audible we have exactly one upstream source and exactly one correct match (and files ideally have one correct checksum). Beyond the initial decryption, I personally prefer to keep the source files untouched. It's the same for my DVD and BD rips: I do my best to maintain the integrity of my archive.
Does your fork also operate from filename, or is that something you would consider implementing?
Thanks again.
Actually the current versions both work off the filename if the tags are missing. If tags are present they take priority.
Currently supported filename syntax is %track% - %album%.
Most of the issues you seem to be having here are with Plex itself, not with this agent. The agent doesn't normally touch the file or the filename.
The scanner parses the files and loads the artist, album, track, etc...
Then the agent takes that already interpreted info and tries to enrich it.
So most of what you are asking for would have to be fixed in the scanner, which comes directly from plex. With episodes or Films you can have custom scanners, unfortunatly you can't do that with Music libs. the plex scanners bundle is here https://github.com/plexinc-plugins/Scanners.bundle.git
To be honest the plex support for audiobooks is pretty bad. I'm going back and forth currently between emby, plex and booksonic and I'm not happy with any of the solutions...
Having said that, I suppose I could look into maybe giving some support for it. But it would depend a bit on what you are looking for exactly.
On Tue, Nov 7, 2017 at 6:59 PM, Aelius [email protected] wrote:
The issue was closed back in July because 1) it was unnecessary and 2) it goes against the convention that is considered pretty standard for the vast majority of audio tracks.
Conventionally music programs rely on tags, yes. But I'm considering the functionality of plex on the whole: a database for general media.
In this subcontext of plex, we have a reliable, consistent, and exact database of IDs (audible). This may not be strictly necessary, but it certainly makes sense within this ecosystem and adds absolute precision to matching. I think that's valuable and topical. In the process of manually matching my audiobooks, I've already found a couple of books that have multiple audible releases, and I've only imported 7 books so far!
And yes, thank both of you for your explanations and help thus far. Thank you for your work on this agent. Even with the manual matching I have to do (*) , the functionality provided is great.
(*) Thanks for the suggestion about m4b @dethrophes https://github.com/dethrophes but I will not be taking that approach; much prefer to see proper mka support implemented in plex.
Actually it was closed because it was working... I haven't used it in a while though.
Basically the syntax was/is to add [audible-] to the Album name.
Ah, album name. That would explain why I couldn't get it to work, as I was hoping to handle this on the file level. While I'm happy to change tags for music files (music is generally its own disorganized beast), in the case of audible we have exactly one upstream source and exactly one correct checksum. Beyond the initial decryption, I personally prefer to keep the source files untouched. It's the same for my DVD and BD rips: I do my best to maintain the integrity of my archive.
Does your fork also operate from filename, or is that something you would consider implementing?
Thanks again.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342568298, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA8zfVZZqZc66WU60ihBnb6HeMnpyIks5s0JqRgaJpZM4OEb9_ .
I mean depending on what you want to do you could add it easily enough yourself, somewhere here https://github.com/dethrophes/Audiobooks.bundle/blob/master/Contents/Code/init.py#L298
The problem I would have, adding a generic implementation is that I would have to give a way to specify the filename format for different users, as the file naming convention you use is not ubiquitous,.
On Tue, Nov 7, 2017 at 7:16 PM, John Kearney [email protected] wrote:
Actually the current versions both work off the filename if the tags are missing. If tags are present they take priority.
Currently supported filename syntax is %track% - %album%.
Most of the issues you seem to be having here are with Plex itself, not with this agent. The agent doesn't normally touch the file or the filename.
The scanner parses the files and loads the artist, album, track, etc...
Then the agent takes that already interpreted info and tries to enrich it.
So most of what you are asking for would have to be fixed in the scanner, which comes directly from plex. With episodes or Films you can have custom scanners, unfortunatly you can't do that with Music libs. the plex scanners bundle is here https://github.com/ plexinc-plugins/Scanners.bundle.git
To be honest the plex support for audiobooks is pretty bad. I'm going back and forth currently between emby, plex and booksonic and I'm not happy with any of the solutions...
Having said that, I suppose I could look into maybe giving some support for it. But it would depend a bit on what you are looking for exactly.
On Tue, Nov 7, 2017 at 6:59 PM, Aelius [email protected] wrote:
The issue was closed back in July because 1) it was unnecessary and 2) it goes against the convention that is considered pretty standard for the vast majority of audio tracks.
Conventionally music programs rely on tags, yes. But I'm considering the functionality of plex on the whole: a database for general media.
In this subcontext of plex, we have a reliable, consistent, and exact database of IDs (audible). This may not be strictly necessary, but it certainly makes sense within this ecosystem and adds absolute precision to matching. I think that's valuable and topical. In the process of manually matching my audiobooks, I've already found a couple of books that have multiple audible releases, and I've only imported 7 books so far!
And yes, thank both of you for your explanations and help thus far. Thank you for your work on this agent. Even with the manual matching I have to do (*) , the functionality provided is great.
(*) Thanks for the suggestion about m4b @dethrophes https://github.com/dethrophes but I will not be taking that approach; much prefer to see proper mka support implemented in plex.
Actually it was closed because it was working... I haven't used it in a while though.
Basically the syntax was/is to add [audible-] to the Album name.
Ah, album name. That would explain why I couldn't get it to work, as I was hoping to handle this on the file level. While I'm happy to change tags for music files (music is generally its own disorganized beast), in the case of audible we have exactly one upstream source and exactly one correct checksum. Beyond the initial decryption, I personally prefer to keep the source files untouched. It's the same for my DVD and BD rips: I do my best to maintain the integrity of my archive.
Does your fork also operate from filename, or is that something you would consider implementing?
Thanks again.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342568298, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA8zfVZZqZc66WU60ihBnb6HeMnpyIks5s0JqRgaJpZM4OEb9_ .
To be honest the plex support for audiobooks is pretty bad. I'm going back and forth currently between emby, plex and booksonic and I'm not happy with any of the solutions...
Even I'm not using Plex to listen to them. I'm just obsessed with keeping things organized. I've got book sonic set up, but I'm just using it for distribution. I'm using a completely different app on Android called Listen Audiobook player. It's the only thing next to the Audibe app that I actually like.
The problem I would have, adding a generic implementation is that I would have to give a way to specify the filename format for different users, as the file naming convention you use is not ubiquitous,.
This is why I was never a big fan of the idea in the first place. Audio is more like TV Shows than it is movies. There are accepted standards on naming conventions that exist for Audio and tagging. Tagging the file names for movies to be used with specific scanners is great - but not a standard. I've done my best to keep this process as generic as possible so that the content would be portable between applications specifically because none of the current solutions are anymore than that just OK.
Making or letting people alter their files to match the scanner defeats the purpose that I originally had. Plus, it puts people down the road of being married to a specific app because it's too much work to change things for another one.
Actually what I'm currently doing is using a second app to export the meta from plex to the filesystem so that booksonic and emby can use it.
Actually I mainly wanted the ability to specify the audible id directly, mainly for the manual searches, sometimes, it's the only way I can get it to match. Though I haven't had that problem since the http to https switch.
What I was more thinking is something like how the youtube agent does it. basically you can specify a python regex to extract the youtube/audible id from the filename. this can then be specified by the user.
e.g. [image: Inline image 1]
There is no real reason not to do something like that, if ppl found it useful, it would be a couple lines of code.
On Tue, Nov 7, 2017 at 8:24 PM, macr0dev [email protected] wrote:
To be honest the plex support for audiobooks is pretty bad. I'm going back and forth currently between emby, plex and booksonic and I'm not happy with any of the solutions...
Even I'm not using Plex to listen to them. I'm just obsessed with keeping things organized. I've got book sonic set up, but I'm just using it for distribution. I'm using a completely different app on Android called Listen Audiobook player. It's the only thing next to the Audibe app that I actually like.
The problem I would have, adding a generic implementation is that I would have to give a way to specify the filename format for different users, as the file naming convention you use is not ubiquitous,.
This is why I was never a big fan of the idea in the first place. Audio is more like TV Shows than it is movies. There are accepted standards on naming conventions that exist for Audio and tagging. Tagging the file names for movies to be used with specific scanners is great - but not a standard. I've done my best to keep this process as generic as possible so that the content would be portable between applications specifically because none of the current solutions are anymore than that just OK.
Making or letting people alter their files to match the scanner defeats the purpose that I originally had. Plus, it puts people down the road of being married to a specific app because it's too much work to change things for another one.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342593271, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA8800emOkFl0VnnNvx7W3DBuNN-uSks5s0K5cgaJpZM4OEb9_ .
You're picture didn't come through. Just says 'inline image 1'
But I guess just call me a purist then. /s
If you want to throw something together for it and it doesn't make something else weird I don't mind including it at all. I just hate the idea of anyone tying things directly to an agent or in this case audible. I'll even throw it in the README, but I would definitely list it as a "for books that don't seem to want to match" or "books that are listed weird on audible."
I just had a conversation through the forum last week with a fellow who never looked at audible to see how the German language version of Game of Thrones were listed and couldn't get it to match. The titles are listed weird in audible and that might be a good use of adding in the ID and not having to change you tags. But then again, that's when I use the manual match....
I threw together what I was talking about more or less. https://github.com/dethrophes/Audiobooks.bundle/commit/8dc7e1f494ade38988538e21cf7de0402bf2ce4d
Tough I don't have the time to test it at the moment. as I'd have to rename files to do so etc...
On Tue, Nov 7, 2017 at 8:53 PM, macr0dev [email protected] wrote:
You're picture didn't come through. Just says 'inline image 1'
But I guess just call me a purist then. /s
If you want to throw something together for it and it doesn't make something else weird I don't mind including it at all. I just hate the idea of anyone tying things directly to an agent or in this case audible. I'll even throw it in the README, but I would definitely list it as a "for books that don't seem to want to match" or "books that are listed weird on audible."
I just had a conversation through the forum last week with a fellow who never looked at audible to see how the German language version of Game of Thrones were listed and couldn't get it to match. The titles are listed weird in audible and that might be a good use of adding in the ID and not having to change you tags. But then again, that's when I use the manual match....
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342601839, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA82jRbPjQHbxBgZYx4ynR98OThVpxks5s0LUngaJpZM4OEb9_ .
I'll throw it on my test server tonight and do some tests. I keep a plex server install on a second box just for testing the agent. Keeps me from having to kick people off when I break something doing a test!
I'll run it through all of my normal agent tests and make up a few new ones for testing this new feature. Be good to have handy for the next time audible gets cheeky with their site code!
@Aelius a regex that should work with this change for the following
filename format is
^(?P
Though that is a bad audibleid as it is no longer on sale, as such it won't show up in search results. Cheers
On Tue, Nov 7, 2017 at 9:39 PM, macr0dev [email protected] wrote:
I'll throw it on my test server tonight and do some tests. I keep a plex server install on a second box just for testing the agent. Keeps me from having to kick people off when I break something doing a test!
I'll run it through all of my normal agent tests and make up a few new ones for testing this new feature. Be good to have handy for the next time audible gets cheeky with their site code!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/macr0dev/Audiobooks.bundle/issues/4#issuecomment-342614937, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbA83SYioOYFdxNc9Zi6gHtKGKm6J_Zks5s0MAbgaJpZM4OEb9_ .
Oh, nice! I'll take a look tomorrow.
But a quick clarification: where the file name is B00IZOP8CI_LC_64_22050_Stereo.aax, the audible id is only the first part: B00IZOP8CI.
You probably knew that already. I'm not sure why the ID didn't work for you: this url brings me right to the page: https://www.audible.com/pd/B00IZOP8CI
True but that isn't how the code currently gets the book entry, it does so via a search. Aside from that, that page actually has syntax errors in it that causes the python json parser to throw and exception. As such it isn't currently possible to do that book for multiple reasons.
As such to parse that particular book, either need to find another json lib that can ignore the syntax issue, write a own parser or something else.
I mean feel free to make your own branch and add these changes, nobody is stopping you.
OK. I'm opening this one back up. I look at what you came up with, but I'm hesitating at it being something that needs to be turned on. Tell me what you think of this.
a regex of both the filename and the album name that checks for a 11 character string at the front that has to contain both numbers and letters and end with a dash. For example:
B00D48L3A6-Lexicon.mp3 : As the file name. or B00D48L3A6-Lexicon : As the album Title
I'm thinking between the number/letter requirement, front of the string requirement, and ending with a dash a nice method could be built for people to name their books or perhaps use it as a manual search method also. Hopefully being that restrictive could mean building it in as an option that doesn't have to be turned on and off to avoid false positives.
Thoughts?