No…this new VM that I built out I exported as an OVA container to import it as a separate VM to try the older version out. I did that specifically because it takes 24+ hours to populate the metadata of my library.
In any event, am getting error when trying to import the OVA I created so I just created a snapshot instead.
for diagnostic purposes only, we usually recommend to create a simple test library with a few items in it only. Quick and easy to debug. faster to burn down and rebuild if needed.
Well now I’m back to a read-only fs…swap is completely empty, can’t create or even auto-fill directories with tab…I’m starting to give up hope on 18.04 and go back to 16.04, where it had 0 issues…
Was able to get into the VM by forcing it into read/write mode on boot. Things it’s noting for failure to boot are:
A start job is running for dev-mapper-Plex\x2d\x2dvg\x2dswap_1.device (XXs/1min 30s)
Timed out waiting for device
Dependency failed for /dev/mapper/Plex–vg-swap-1
Once I was back in with write privileges, I found a random UUID in the /etc/fstab file. Was then able to run a ‘mount -o remount,rw /’ and no errors came back. Now it’s booted back up and seems stable again…may be further proof that I need to get this share mounted as an nfs…
There still, however, is no swap…
Tasks: 133 total, 1 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.0 us, 1.9 sy, 0.0 ni, 98.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 9.4 us, 5.7 sy, 0.0 ni, 71.7 id, 13.2 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 5.9 us, 2.0 sy, 0.0 ni, 80.4 id, 7.8 wa, 0.0 hi, 3.9 si, 0.0 st
KiB Mem : 8168460 total, 7446864 free, 298652 used, 422944 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7617140 avail Mem
At this point, I need to step out. It’s an OMV VM issue. I have no way of helping with that.
Officially, we don’t support OMV so that makes it harder for me to justify .
Best I can recommend is the OMV forums. Sorry
I’m not sure why you keep saying it’s an OVM issue. The only time an OVM came into play was to backup, export, and import a new VM as a test, which I noted earlier I gave up on. This is a vanilla 18.04 VM turned up from scratch and PMS installed on top of it…
What is the VM running on?
ESXI or ??
And by OVA, do you mean the Appliance export OVA format?
Yes, it’s running on an ESXi 6.0 box
And yes, I meant i was trying to export it as an OVA template (a .iso wrapper form of export for the VM).
Try it this way. Let that guest sit completely off to the side.
Start fresh.
Basic 16.04 LTS
I don’t trust OVA’s because of the paths and other system depending things which can come over in it as it relates to PMS
Doing that now. I think v18 is causing too many layers of complexity. At least if I get i working on 16.04.4, then I can snapshot the VM and try a release upgrade. Starting the 16.04.4 install now. I likely won’t have any updates for about a day. Once plex is installed, it’ll take 24+ hours to populate the metadata.
Upgrading any ubuntu is problematic. it seems to be their signature from 16 - 17 and 18
16.04 running PMS 1.13.4.5271, same addedto timestamp as before. See below XML output. This is before any metadata is even populating.
<MediaContainer size="1" allowSync="1" identifier="com.plexapp.plugins.library" librarySectionID="1" librarySectionTitle="Movies" librarySectionUUID="69da4c83-2967-4460-982c-a7c7e2c3ee88" mediaTagPrefix="/system/bundle/media/flags/" mediaTagVersion="1531970632">
<Video ratingKey="268" key="/library/metadata/268" guid="com.plexapp.agents.imdb://XXXXXX?lang=en" librarySectionTitle="Movies" librarySectionID="1" librarySectionKey="/library/sections/1" type="movie" title="XXXXXX" summary="" thumb="/library/metadata/268/thumb/1544403241" art="/library/metadata/268/art/1544403241" duration="5992128" addedAt="4039387200" updatedAt="1544403241" chapterSource="media">
<Media videoResolution="720" id="288" duration="XXXXXX" bitrate="6266" width="1280" height="696" aspectRatio="1.85" audioChannels="6" audioCodec="ac3" videoCodec="h264" container="mkv" videoFrameRate="24p" videoProfile="high">
<Part accessible="1" exists="1" id="289" key="/library/parts/289/4039387200/file.mkv" duration="5992128" file="/mnt/smb/Movies/Movies/XXXXXX" size="4693567999" container="mkv" videoProfile="high">
<Stream id="2975" streamType="1" default="1" codec="h264" index="0" bitrate="5626" bitDepth="8" chromaLocation="left" chromaSubsampling="4:2:0" frameRate="23.976" hasScalingMatrix="0" height="696" level="41" profile="high" refFrames="9" scanType="progressive" width="1280" displayTitle="Unknown (H.264 High)"/>
<Stream id="2976" streamType="2" selected="1" default="1" codec="ac3" index="1" channels="6" bitrate="640" language="English" languageCode="eng" audioChannelLayout="5.1(side)" samplingRate="48000" displayTitle="English (AC3 5.1(side))"/>
</Part>
</Media>
<Extras size="0"> </Extras>
</Video>
</MediaContainer>
Going to let the metadata finish populating and I’ll report back tomorrow. Done tshooting this for today…
Ok, I feel really dumb that I didn’t notice this…Metadata got populated on the 16.04 server and populated the same addedat date for the same files. I looked at the actual files and turns out that Plex (assuming on the first 18.04 server) manipulated the modified dates of the files on the NAS to be 2038 or 2097 for the year. I bulk changed the files to be 10/2018 or earlier, did the Plex Dance for those files, and I think it’s fine now. Going to move over new files in those libraries and see if that fixes it. If it does, I’ll close out this thread. Thanks for the assistance, Chuck. Should have checked the files first…
Yep, seems to be functional now…Sorry about all that. Feel free to close out/lock this thread.
For anyone that encounters this issue, first look at your files themselves and see if the modified date is in the future. If you do, I found that BulkFileChanger from Nir Sofer was the easiest tool to use to change this.
Thanks again for the help, Chuck!
