Did you test this?
According to Jam, the framework is using bundled python on all platforms. Not relying on installed python or it's limitations. As I understand it, this should work on all PMS instances that are at least moderately recent.
Yes, I tried it on v0.9.9.13.59-92b95bc - debian PC i686
(Above is how it shows in the logs for QNAP)
And after copying the file _sqlite3.so to the following path: /share/MD0_DATA/.qpkg/PlexMediaServer/Resources/Python/lib/python2.7/lib-dynload I could load the plug-in
Haven't tested it though yet, but now it @ least loads, and shows in the channel
So seems to me like we need to grease the NAS builds a tad here, maybe with some jam ;)
/T
And just to clarify a tad here.
My QNAP box is 100 % clean, and not running any python nor SQLite besides the ones in Plex.
It's my dedicated test box, and gets wiped @ least once every 3rd. month
/T
I mentioned that sqlite3 isn't available for import on QNAP PMS boxes and the response was not encouraging. Looks like a hacky work-around is what's needed.
If we're considering adding files for sqlite support, where do they need to reside when all is said and done?
Do we need to copy files to the user's python PATH or just into the plugin's code directory?
I'll have to get back to you on that one.
(Will have to do some testings here)
But do note, that QNAP isn't the only platform affected, since it's according to Tobias based on the NetGear builds.
And I suspect, that other NAS vendors also might be affected by this.
And FWIW:
First test of the plugin never ran the wizard, but did allow me to lock a section, leaving me locked out for now :D
(And maybe this is related to this one: https://forums.plex.tv/topic/113889-no-welcome-wizard/?hl=welcome )
(Kinda fear, that dict's might be broken somehow, but sadly nobody picked up on the thread)
/T
Also do mention to Jam, that I can provide him with the missing .so files for both Intel and ARM builds, so it's really a No-Brainer to get them included in the builds.
All that has to be done, is putting the files in there.....no configuration is needed!
/T
I'll have to get back to you on that one.
(Will have to do some testings here)
But do note, that QNAP isn't the only platform affected, since it's according to Tobias based on the NetGear builds.
And I suspect, that other NAS vendors also might be affected by this.
And FWIW:
First test of the plugin never ran the wizard, but did allow me to lock a section, leaving me locked out for now :D
(And maybe this is related to this one: https://forums.plex.tv/topic/113889-no-welcome-wizard/?hl=welcome )
(Kinda fear, that dict's might be broken somehow, but sadly nobody picked up on the thread)
/T
Really strange that it would lock a section without having run the wizard as it wouldn't have any stored values to execute the lock command.
Really strange that it would lock a section without having run the wizard as it wouldn't have any stored values to execute the lock command.
And I was wrong here....
It did ran the wizard, but.....
I sadly didn't follow your guide, regarding the search field....SIGH.....
So reinstalled, and tried it again, after putting the so file in place, and this time entering the pwd. in the search field....
It then asked me to confirm it, but that sadly didn't work....
Log attached
Some more feedback here, even though I still simply can't get the darn logic to work on my QNAP's.
( And granted....Yes....I'm using the WebAdmin Interface, which you guy's say will not work, but still trying here :rolleyes: )
Instead of walking every item and set the timestamp, it might be a tad more easy to switch the section into not show on deck?
library_sections table:
Field: user_fields
Add the following: pr%3AincludeInGl
That way, there's no need to walk every item, which could take a long time for a huge section!
Also, you are deleting the item from the library_section table.
I suggest instead, that you do the following:
Change the field "name" into "HIDDEN", and store the origen name in a dict.
Then change the integer field named "section_type" from it's origen value into value + 666
(Above is number of the beast, and since a section that big is not defined, no browsing to it is allowed)
With above, the section is still avail, but with a name of 'hidden', so in my book a tad more safe, in case a user uninstall the plug-in, since the database still can be edited
And if not wanting to use the dict to store stuff, we can take it a tad futher, by doing the following:
For the field 'user_fields', add stuff like:
pr%3AincludeInGlobal=0&name=&type=
That way, the dict is used only for the password, but even that could be stored like above, allowing individual pwd for each section :)
And to retrieve stuff, like the origen section name, use a query like:
SELECT user_fields FROM library_sections where name = "HIDDEN"
Then digest the returned string
All above is though based on looking @ the code, and not trying in real life, since still trying to get it to work here, so your solution might be fine, but IMHO dangerous, if user uninstall the plug-in
Best Regards
Tommy
EDIT: No need to add the type to the database field, since one simply can substract 666 from the value to get the origen one
And adding here to self....
Switching the type to an undefined integer was fine for the Web-Admin interface, but didn't work for a client i tried (Samsung)
However, instead of adding 666 to the type, add next number in line to the id, and we have a go.
To grap the next number, use this query and add 1:
SELECT MAX(id) FROM library_sections
And then we have to store the origen id in the user_fields
/T
Some more feedback here, even though I still simply can't get the darn logic to work on my QNAP's.
( And granted....Yes....I'm using the WebAdmin Interface, which you guy's say will not work, but still trying here :rolleyes: )
I would suggest testing with either PHT or a mobile client for setup purposes.
Instead of walking every item and set the timestamp, it might be a tad more easy to switch the section into not show on deck?
As previously mentioned, I'm a sqlite noob but I was under the impression that editing the timestamp values for the section didn't require each item in the section to be edited. :unsure:
I would suggest testing with either PHT or a mobile client for setup purposes.
As previously mentioned, I'm a sqlite noob but I was under the impression that editing the timestamp values for the section didn't require each item in the section to be edited. :unsure:
Lots going on, thank you so much Mike and Tommy.
Umm, I remember one of the posts we were conversing about what is safe whilst messing with the DB. Messing with parts (columns) of a row, for instance, in the library_sections is not the best thing to do.
PMS although not an AI :D yet, will know something is there, either the whole row should be removed or should exist. This is my humble opinion and is most def not the only way! It is just the way to avoid unforeseen drama/db corruption.
Tables have a primary key column i.e. a sort of unique value based on the datatype of that column. In the library_sections table, I believe it is “id” so a “id” must exist for corresponding data to exist. So long as “id” exists, PMS will scan it, look at it, read it, digest it and spit it out! (My understanding), changing values in the row may have a ripple effect on something else. This is, in my humble opinion, the epicenter of how bad ■■■■ happens to databases. This is PMS lol, plex users will not be forgiving! ;)
Once again, thank you for taking the plugin to another level! : )
I would suggest testing with either PHT or a mobile client for setup purposes.
Hehehe.....guess it's time to actually try PHT then :rolleyes:
As previously mentioned, I'm a sqlite noob but I was under the impression that editing the timestamp values for the section didn't require each item in the section to be edited. :unsure:
LOCK_COMMAND_1 = "UPDATE metadata_items SET added_at=? WHERE library_section_id=?;"
/T
Lots going on, thank you so much Mike and Tommy.
Umm, I remember one of the posts we were conversing about what is safe whilst messing with the DB. Messing with parts (columns) of a row, for instance, in the library_sections is not the best thing to do.
PMS although not an AI :D yet, will know something is there, either the whole row should be removed or should exist. This is my humble opinion and is most def not the only way! It is just the way to avoid unforeseen drama/db corruption.
Tables have a primary key column i.e. a sort of unique value based on the datatype of that column. In the library_sections table, I believe it is “id” so a “id” must exist for corresponding data to exist. So long as “id” exists, PMS will scan it, look at it, read it, digest it and spit it out! (My understanding), changing values in the row may have a ripple effect on something else. This is, in my humble opinion, the epicenter of how bad ■■■■ happens to databases. This is PMS lol, plex users will not be forgiving! ;)
Once again, thank you for taking the plugin to another level! : )
Hi there.
Yes, I agree that messing with a primary unique key isn't something that should be done in a rush, but what I've done so far, was manually editing the fields, and it worked nicely.
Regardless, I would say, that a primary key is a key just like any other, so actually fails to see the problem here, or?
/T
And a followup.
It looks like the library_section is created without a Foreign Key Constraints when looking in the master table.
As such, my suggestion would break relations between the section table and the media_items table, but that's what you are doing as well?
Anyway, regardless, I think I found a "security" issue with both your metode and mine
It seems like you from the Web-Admin interface can search for a movie in a locked section, and actually find and play it, regardless of the fact, that it doesn't belong to a section anymore :(
/T
Hi there.
Yes, I agree that messing with a primary unique key isn't something that should be done in a rush, but what I've done so far, was manually editing the fields, and it worked nicely.
Regardless, I would say, that a primary key is a key just like any other, so actually fails to see the problem here, or?
/T
Hey,
you'r right, primary key is just a key, it is sometimes used to connect 2 or more tables. In this case the primary key is being generated by a sequence, if that sequence gets corrupted coz of manually incrementing the primary key and inserting a new row, that's bad. All I'm saying is that it is better to not mess around with.
And a followup.
It looks like the library_section is created without a Foreign Key Constraints when looking in the master table.
As such, my suggestion would break relations between the section table and the media_items table, but that's what you are doing as well?
Anyway, regardless, I think I found a "security" issue with both your metode and mine
It seems like you from the Web-Admin interface can search for a movie in a locked section, and actually find and play it, regardless of the fact, that it doesn't belong to a section anymore :(
/T
Yes, that is what I am doing as well :)
LOL @ "security" issue. There's always something, right? I don't mean to sound negative but bummer man. I never checked the search field. Thanks for the heads up. Btw I don't see how to change the "security" flaw without having a look at the search query that gets fired from within PMS. Shucks!
Hey,
you'r right, primary key is just a key, it is sometimes used to connect 2 or more tables. In this case the primary key is being generated by a sequence, if that sequence gets corrupted coz of manually incrementing the primary key and inserting a new row, that's bad. All I'm saying is that it is better to not mess around with.
But that's what my tests showed....SQLite handles this very nicely, and will always add +1 to the MAX(id) key.
But regardless, your baby, your decision ;)
LOL @ "security" issue. There's always something, right? I don't mean to sound negative but bummer man. I never checked the search field. Thanks for the heads up. Btw I don't see how to change the "security" flaw without having a look at the search query that gets fired from within PMS. Shucks!
Agreed, and this could sadly be a show-stopper :(
Unless you go ahead with this flaw, and simply put in a warning to people about this
/T
Thanks, updated OP with the warning.
There is probably a way to block the movies from appearing in search. Will have to look into users for PMS and how to share some movies/sections with just those users. Probably a flag for the search query to avoid! A co-relation of sorts bdetween the tables (library_section_permissions, metadata_item_accounts) prolly get populated once user(s) created!
Appreciate everybody's contribution :)
Thanks, updated OP with the warning.
There is probably a way to block the movies from appearing in search. Will have to look into users for PMS and how to share some movies/sections with just those users. Probably a flag for the search query to avoid! A co-relation of sorts bdetween the tables (library_section_permissions, metadata_item_accounts) prolly get populated once user(s) created!
Appreciate everybody's contribution :)
I sadly think, that the library_section_permissions table is used with sharing, and as such, not valid for us....SNIFF....
/T
