openmediavault-emby plugin (formerly mediabrowser)

    • Offizieller Beitrag

    The message he sent me said "all of his computers+tv+roku+routers" :(

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Hopefully not a lot of stuff got ruined at Serg's house. I guess his wife called him at work and he rushed home. Wife said sparks came out of plugs or something. Lightning storm.


    All the electronics in my house are toasted. Even I'm using three UPS, one being industrial, nothing saved. Lightning entered through the phone line and from the router distributed through the net line to all the equipment connected. the Roku has a hole on the board in front of the RJ port. The Denon receiver (only 3 weeks o life) sent the overload tru the hdmi to the 52" TV (that didn't have net) and fried half it's board. A switch, my beloved supermicro board... I spent all morning with the technician and Monday will pray that the insurance pays half of this. As phone co also lost their communications there I'm at a wifi spot on my wifes latop.
    And then this.


    That is a NoGo!


    Excuse me sir, but the problem there it's that the folder selector doesn't get the user selection for folder, as the three first users stated. The plugin does nothing for deleting during the install. The logic there only finds for the old cache folder (a specific folder that was inside the program folder) and then copy to the place Aaron told me: /var/lib/mediabrowser.
    Then it replaces the entire program folder with the new version. It does like this to prevent the new version to delete the user configuration. POINT.


    Zitat

    I just had a quick lok at the plugin-code, but can't find any problems with it on the first sight.


    Because it's the OMV GUI that's failing. You never faced this problem because while I was developing the plugin I did not find any other plugin that moved folders, all of them told their guests programs to do it or triggered something after changing their program configurations.


    When the plugin is installed, it should offer the user the choice for moving /var/lib/mediabrowser/PROGRAM-DATA (program-data created by mediabrowser if new install) to it's specified location choice. But OMV interface seems to fail to get the users destination and it puts the location at a root volume
    I did not made the folder selector. Even I did not incorporated to the plugin.


    I didn't expect to be blamed for my first contribution. I only got a personal disaster and no-one cared about those people there asking for help, but raged while I was offline.



    I posted warnings everywhere and done tons of tests. I compile this at a real x64 machine, not VMs, and tested in real machines tru all the week. New installations and updates. 3 times on every machine. Only have a problem with the plugin creating cascaded ./Program-data/Program-data/Prog... folder. And posted instructions before runing home. I'm using it in my personal server.


    I did tell him that most of the plugins don't delete database files and it can be dangerous.


    That's not fair. We discussed about the nature of this folder. Being a metedata/art and transcoding container could be gigs size. And that users where having problems with their system disks overloaded. Then you agreed to the necessity of removing this with the plugin. Further tests could have been done, of course. But I didn't have material time to do more tests.


    Although the solution to this problem was as easy as instruct people to remove the data-folder and data-folder_old configuration entries before uninstall. And of course freeze the repo for preventing new installations.


    The MB can't work with a cache folder without privileges. It has to remove the temp-transcoding files and plenty other things. how a media server can work without that? But that's not the problem.
    Your confusing the media content with the inner Mediabrowser DB folder. MB needs to take care of it's own folder. Please instruct me if I'm wrong.


    And there are two points there:
    GUI failed to get user will (Disk+folder)
    User also confused the program cache folder with their media content.


    That happened probably there:

    Code
    // Get path of mntentref and set db-folder to this path        if ( empty($params['mntentref']) == false )        {            $xPath = sprintf("//system/fstab/mntent[uuid='%s']", $params['mntentref']);            $deviceDir = $xmlConfig->get($xPath);            $deviceDir = $deviceDir['dir'];
                $dbFolder = "{$deviceDir}/mediabrowser";            $params['db-folder'] = $dbFolder;        } else {            $params['db-folder'] = "/var/lib/mediabrowser";        }
  • Thanks Eraxar!!


    Serg, mediabrowser needs to be owner of its own folder that has the database and other related files. It does not need to be an owner or user of the media shares and files on people's OMV. Most media programs only need to be able to read those media files. So in linux mediabrowser only needs chmod 775 (files loaded via SAMBA will actually be 664), where the 5(4) is all other users can read.


    Now that said, this will disable the delete file functionality in the Roku, for example. That is because in a multi user environment you normally do not want all users to be able to delete files.


    The meta data should be removed with the plugin. Normally when you remove a plugin you want to erase everything that was installed and created by the plugin (& program). If you want to save this data you should make a copy before removing the plugin.

    • Offizieller Beitrag


    That's not fair. We discussed about the nature of this folder. Being a metedata/art and transcoding container could be gigs size. And that users where having problems with their system disks overloaded. Then you agreed to the necessity of removing this with the plugin. Further tests could have been done, of course. But I didn't have material time to do more tests.


    I didn't say it wasn't the right way to go. I was just saying I warned you that it could be dangerous :) Either way, the plugin should be fixed and still removes the files. I installed and uninstalled it a lot of times!

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • PlexMediaServer and owncloud plugins both move a working directory to a data drive.


    In Plex it is the plexmediaserver folder.
    In ownCloud it is the data folder.


    It was the right thing to move the items you did Sergio.

  • @tekkb, I never took ownership of the media files of the people. That was the interface not picking the folder location, only the mntentref.
    I made the plugin to let the user pick the disk but also the destination (I recognize I don't understand that selector thing well) and I would add one level at saving (mediabrowser adds it's own level).
    Saving should join disk and folder to build the location and not allow empty folder, but It seems that I didn't coordinate with Aaron.
    I guess he thought that it had to let the user only choose a "disk" and supply a fixed string "Program-data" or in his last edits "cache". I never meant the plugin to use a root+ fixed name, so in the opposite side it caused a redundant folder creation when mb started.
    So at some point I fixed it for not to happen and that would had let the mntentref alone to save as the folder wanted.
    I didn't consider that option as it's mediabrowser who creates it's cache folder at the first run. that's what caused the redundancy at the plugin level.


    Now he's altering the plugin to consider the inners of the cache data of MB and process them, but he would not know all the elements mb will save inside or them could change in the future. Perhaps the redundancy will happen again.


    By now I'm so depressed, mainly by the lost caused by my plugin, that I don't have any courage for anything. I did it for fun, and that's not.

  • It was the right thing to move the items you did Sergio.


    I Don't understand. But if your saying that the cause of the failure was my coding for moving the folder... that's right. could be.
    Next time, I'll ask the users to remove previous installations and not moving old folders to allow upgrades. If that time comes.

    • Offizieller Beitrag

    Because the plugin downloads the latest version, you always run the risk that it doesn't work right. That is why we update the plugins :) If you don't update the plugin, it should keep working right.


    Your code was fine. We both missed where it was putting files. The plugin is working good on my VM now :) Plenty of people deleted files because they didn't read Volker's messages when deleting a shared folder. So, it happens. There have been a lot of people happy with this plugin and would love to see it advance :)

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Sergio, I was talking about the design of the plugin, not your coding. It was right to move the caching, meta files, etc.. from the operating disk to a data disk.


    So what have we learned??? Test a bit more before release.


    Sergio, you did not lose your plugin. There are just little things here and there that needed to be adjusted. It happens with all the plugins. Just sometimes it might be more serious problems than other times.

  • Sergio:
    No offense! Thanks for your work on the plugin


    I meant by "This is a NoGo!" that it is a NoGo that ANY plugin can delete the users mediafolders, even by mistake. As Aaron or tekk said, it wasn't tested enough.
    If the DB/Cache for mediabrowser were in a subfolder on the drive, than nothing like this had happend.
    The "KillSwitch" was rm -rf $DATAFOLDER and not rm -rf $DATAFOLDER/mediabrowser
    I'm the last one, who wants you to loose your plugin, keep up your good work on it


    I hope you get your home fixed soon and it is all cleared now. If my post sounded too hard, then I apologize. I don't meant your work, but the plugin, as mentioned above.

    • Offizieller Beitrag

    In his defense, I think we both did testing on fresh VMs with only this plugin installed. You would never know it was deleting anything because we didn't have anything on there to delete. The code in question was copied almost exactly from plex. The word plexmediaserver was erased and not replaced with mediabrowser - line 147 of the code. If it had been, there would've been no issues. The rm -rf line uses the db-folder setting in config.xml which would've had the mediabrowser part then. All the other changes I made were to make sure nothing happened to people when upgrading from 1.0.2.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!