I sent those to you directly.
The Network support page says this:
Private/LAN addresses can be specified either as a range or as an individual IP address. Public addresses can only be specified as an individual IP address
Has this behavior changed?
1 Like
I am looking further into this to establish if this is a bug or the intention
1 Like
I notice that an individual IP address put in ... allowed without auth is accepted quietly. There’s no error message like there is when entering a range.
I also notice that requests from individual public IP addresses are logged differently, and it looks like they should succeed.
… DEBUG - Request: [9.10.11.12:13141 (Allowed Network (WAN))] …
I don’t use the feature myself. If the intention is to remove it, it seems like it’s in a weird state at the moment.
Whilst some logging indicates it was accepted, the end result is that the whitelisting of the public IP address gets ignored.
It does not work and with the moves towards tighter security for Plex Media Server, this is not going to get changed.
We will update the support article to remove the reference to public IP addresses
1 Like
PMS for Mac 1.30.0.6442 & 1.30.0.6486 continues to:
- cause PMS host Mac severe instability;
- creating corrupt PMS recording database entries or serving wrong recorded show
For example, without nerdly admin (ie, me) manually permanently deleting PMS host Mac Saturday Night Live (“SNL”) recorded files, users can not play the current season SNL shows despite Plex player UI and show file Get Info explicitly indicating PMS is attempting to play the current SNL show file.
You mention a number of issues on the attached screenshot - Best to split these as separate issues and raise individually
For the first - which you annotated in red text you say the file is not playable - the screenshot shows the media item as UNAVAILBLE - is the path showing below Files available? Are the permissions correct? The logs would show what error Plex Media Server is getting - eg Permission Denied or Not Found. The logs would need to be captured when attempting to playback this UNAVAILABLE file. Then we can see if it is a permssions error or the path is no longer available
I am referring to the .ts file under /Volumes/12TBHD1/
For the second - annotated in green, you mention Saturday Night Live airing immediately after at 22:02 PST - what should this have been ? The screenshot shows the recording named as Tom Hanks one? what should it have been ? What channel number/ channel name / what zip code/timezone ? Would need the channel schedule and what supposed to be recorded and what happened instead.
For the third, annotated in blue, are you saying the recording started 1 minute late ? starting at 20:30 when you expected it to start at 20:29? Would need debug server logs covering time of any recording that does not start at the expected time. You also mentioned cannot be played - like the first would need to establish if the path to the file is accessible - again debug server at the time of the failure to playback
For the 4th - annotated in purple, this is similar point you are raising to that for Tom Hanks. What should this recording at 22:02 have been ? Would need the channel schedule and your DVR Recordings schedule to understand what the issue is and what should have happened
I see you sent me server logs - i will have a look to see if they cover any of the issues identified above
I cannot see references in the logs provided to the first file that you say cannot be played. The S48E08 episode of Saturday Night Live epsisode : Steve Martin; Martin Short; Brandi Carlile
You mentioned you are having to manually delete the recording file - may be that is why it is showing as UNAVAILABLE - because you deleted the file and have not emptied the trash in the library and so shows up as UNAVAILABLE
I would need logs captured before you do the manual deletion to show the issue that you mention - which is that the recording cannot be played
In the provided logs - I see two recordings made for
Rick Steves Why We Travel (2022) - 2022-12-11 02 30 00 - Rick Steves Why We Travel
at 02:30 on 11th December on channel 9.1
and
Joel Osteen (1999) - 2022-11-28 15 06 36 - Favor in the Storm
at 07:00 on 11th December on channel 56.1
For Saturday Night Live - I see intended recordings for 3 episodes scheduled -
for
A Saturday Night Live Christmas Special
E9 - Austin Butler; Yeah Yeah Yeahs
Kristen Wiig; Dua Lipa
Dec 11, 2022 03:00:02.489 [0x70000117f000] DEBUG - Subscription: No match in the library for 'Saturday Night Live - A Saturday Night Live Christmas Special', grabbing.
Dec 11, 2022 03:00:02.489 [0x70000117f000] DEBUG - Subscription: No match in the library for 'Saturday Night Live - E9 - Austin Butler; Yeah Yeah Yeahs', grabbing.
Dec 11, 2022 03:00:02.489 [0x70000117f000] DEBUG - Subscription: No match in the library for 'Saturday Night Live - Kristen Wiig; Dua Lipa', grabbing.
These being scheduled for the following airing times
Dec 11, 2022 03:00:05.053 [0x700001c3e000] DEBUG - DVR:NewSchedule: Between 2022-12-14 20:00:00 and 2022-12-14 22:00:00 on channel 5fc76b256b022a002d866f53-5fc705ffc8d56d002e06f948: 'Saturday Night Live - A Saturday Night Live Christmas Special'
Dec 11, 2022 03:00:05.054 [0x700001c3e000] DEBUG - DVR:NewSchedule: Between 2022-12-17 20:29:00 and 2022-12-17 22:02:00 on channel 5fc76b256b022a002d866f53-5fc705ffc8d56d002e06f948: 'Saturday Night Live - E9 - Austin Butler; Yeah Yeah Yeahs'
Dec 11, 2022 03:00:05.054 [0x700001c3e000] DEBUG - DVR:NewSchedule: Between 2022-12-17 22:02:00 and 2022-12-17 23:00:00 on channel 5fc76b256b022a002d866f53-5fc705ffc8d56d002e06f948: 'Saturday Night Live - Kristen Wiig; Dua Lipa'
These times
2022-12-14 20:00:00 to 2022-12-14 22:00:00 A Saturday Night Live Christmas Special
2022-12-17 20:29:00 to 2022-12-17 22:02:00 Saturday Night Live - E9 - Austin Butler; Yeah Yeah Yeahs
2022-12-17 22:02:00 to 2022-12-17 23:00:00 Kristen Wiig; Dua Lipa
These being on channel 5.1 : KINGDT (KINGDT (KING-DT) Affiliate: NBC)
Is this what you are expecting ?
Yesterday, 13 December, yet again PMS for Mac 1.30.0.6486 f’up (again) the displaying, in Season 8 of The Late Show with Stephen Colbert the previously recorded 8 November, as if a duplicate thumbnail of the 13 December show.
(See:
)
may be the airing is incorrectly identifying itself in the schedule and leading to Plex Media Server not establishing that it has already been recorded
For issues like this - would need actual filenames of the recordings - you can get that from the media info view in Plex Web and also selecting View XML and copying the displayed output into a text file and saving that and then zip and upload the zip with screenshot of the text media info display
Also would be useful to get a full directory listing of the folder for the show listing subdirectories and recording files
And to indicate which channel number / channel name the recordings were from - I already have your zip code so can look up the lineup and channels
I will have a look at your linked recording priority forum topic next
An observation: You are now reporting DVR EPG / recordings issues in a forum topic that was for server crashes - I would suggest you switch to separate topics for the EPG / DVR issues
The title of this topic bears no relation to the issues being discussed now
So lets close this off and switch to new topics for the DVR recordings / schedule issues you are seeing
There were, and are, currently on-going (at least through PMS 1.30.0) two significant issues reported in this topic for the last 10 weeks:
- PMS instability apparently beginning with 1.29 (or 1.28.2 ???); and
- PMS apparently corrupting its database, or erroneously displaying and serving recorded shows.
Having no access to PMS architecture design, 10 weeks ago I had no insight as to whether these two issues were related to the same bug or merely that they manifested in my awareness upon installing PMS 1.29. (Reverting back to 1.28.2 did not resolve PMS stability, but I can know if that was due to 1.28.2 or a possibly corrupted database.)
Issue 2 has been a real pain in the rear. There have now been several, apparently successfully, recorded OTA TV show episodes (eg, Saturday Night Live, and now, The Late Show with Stephen Colbert) that, seemingly, can not be played without my manually deleting a previously recorded episode from the PMS for Mac host file system. Even then, such episodes can only be played by Plex for Mac, but can not be played using Plex for Apple TV, nor Plex for iOS.
Issue 1 may have resolved, but given a recent (PMS 1.30.0.6486) failure to record the highest priority show, I’m not sure.
.
I did create a separate topic. I cross-referenced that other newly created topic, once in this topic, in as much as that other apparent bug appeared to have arisen from recent (>1.28.1) PMS changes and, potentially, may be closely related to issue 2 listed above.
Thank you for caring.
.
For each “unplayable” episode, I have always examined, and I have posted (or messaged directly to you) the “unplayable” episode > Get Info > Media Info > Files file path (herein the “Get Info File Path”). The Get Info File Paths listed have always been precisely the (PMS host Mac filesystem) correct path to the desired recorded episode.
For example, the 10 December 2022 8:29pm PST – 10:02pm PST current season new SNL S48E08 “unplayable” episode correctly has the Get Info File Path:
“/Volumes/12TBHD1/Plex/TV Shows/Saturday Night Live (1975)/Season 48/Saturday Night Live (1975) - S48E08 - Steve Martin; Martin Short; Brandi Carlile.ts”
Further, I have verified with several that the apparently successfully recorded episode file is playable by QuickTime Player.
As I have previously posted, it (very strongly) appears that the Get Info File Path (ie, what is displayed to the user) is not the controlling link to what is actually being served by PMS to the the Mac, Apple TV and iOS Plex player apps for these aberrant episode since installing PMS 1.29.
Example, when upon initiating the playing of the above reference SNL S48E08, a completely different recording is played, in this case, the recording of the immediately subsequent airing of the SNL “vintage” (ie, rerun from a previous season) episode stored in the Season 48 directory, labeled in the GUI as “12/10/22” having the Get Info File Path:
/Volumes/12TBHD1/Plex/TV Shows/Saturday Night Live (1975)/Season 48/Saturday Night Live (1975) - 2022-12-10 04 00 00 - Tom Hanks; Edie Brickell & New Bohemians.ts
.
Having also examined at length the … [More] > Get Info > Media Info > View XML (herein the “Get Info XML”) of both aberrant episode recordings and recordings of episode without any apparent playback issues, it (very strongly) appears that the Get Info XML (ie, what is displayed to the user) following (noteworthy) attributes are not the controlling links to what is actually being served by PMS to the the Mac, Apple TV and iOS Plex player apps for these aberrant episode since installing PMS 1.29 (eg, these differ between SNL Season 48 episodes “Episode 8” vs “12/10/22”):
<MediaContainer
<Video
key
guid
thumb
<Media
id
<Part
id
key
file
</Part>
</Media>
</Video>
</MediaContainer>
I have attached two text files containing both the Get Info File Path and full Get Info XML associated with the above two referenced SNL episodes:
pl4151 new SNL > Season 48 > episode “Episode 8” Get Info > Files & View XML.txt (8.8 KB)
pl4151 vintage SNL > Season 48 > episode “12:10:22” Get Info > Files & View XML.txt (9.0 KB)
There have been a number of recent fixes for crashes and hangs
In latest beta 1.30.1.6497 two causes were fixed
- (Bandwidth) Server could become unresponsive under certain timing conditions (#13951)
- (Database) Server might quit unexpectedly after SQLite3 syntax errors (#13942)
and in 1.29.2.6364
- (EPG) Server might become unresposible when parsing special episodes in XMLTV guide data (#13117)
- (IntroDetection) Decreased memory consumption for intro detection (#13361)
- (Library) Running a Clean Bundles operation could crash the server (#13855)
- (Maintenance) Plex Media Server could quit unexpectedly when asked to clean bundles under certain conditions (#13855)
If you continue to have crashes and hangs /server becoming inaccessible then we can investigate - but I am not aware of any such issues remaining on your system
This is not database corruption but could be issues of matching DVR recordings incorrectly or a mismatch between EPG metadata and thtvdb or tmdb
For a long time now, we had a recommendation that DVR recordings should go into dedicated libraries for recordings and should not be mixed and included other TV and Movies libraries
This is mentioned in this pinned forum topic in the Live TV & DVR forum category
You could as an experiment create a new TV Shows library and a new Movies library to hold only recordings and not mixed with any other media files and to have their own filesystem directory structure. This is advised because sometimes there may be a difference between how the EPG identifies airings to what is held on thetvdb or tmdb - and you would ensure you would retain the EPG data and not to force match a show - thus preserving whatever the EPG has for the metadata.
So I suggest you start by modifying scheduled recordings to switch to these dedicated recordings libraries - perhaps starting with Saturday Night Live and The Late Show
As the TV Recordings library is a new empty library to start with, this will mean you would start to get recordings for episodes that you may already have in the older libraries - you can delete the old libraries media files when you now have the equivalent ones in the new dedicated recordings libraries
Well - the last one you mentioned showed “UNAVAILABLE” on the screenshot - which could be because it was deleted
Also would need to understand what is meant by Unplayable. Is it that you get an error ? or is it that Plex Media Server is picking a different file than the one you expected it to pick ?
Either way - i would need debug server logs for when the file is unplayable to accompany the screenshots and media info xml
I could look into your database to see what you have in the database for the Saturday Night Live show and also look at your EPG database to see what channels broadcast this show
But - switching the recordings to a new set of libraries dedicated to recordings only and preserving the EPG metadata may resolve the issues
PMS for Mac 1.30.1.6497 become FUBAR ~8:21pm PST this evening.
The PMS for Mac host is dedicated to PMS, and essentially completely idle. The PMS host Mac Activity monitor showed negligible CPU activity, ~0.7% of possible 800%.
(The PMS for Mac host CPU has 4 i7 cores x 2 for hyperthreading:
27" iMac (2010) 2.93GHz Core i7, 4 cores, 20GB RAM, 1TB boot volume [376GB free]
with ATI Radeon HD 5750 1024 MB GPU
macOS 10.13.6
PMS Library store: 12TB dedicated WD drive [3.5TB free] )
Like you, it seemed to me that PMS 1.30.1.6497 was more stable. Unfortunately, it appears we were both wrong—PMS for Mac 1.30.1.6497 tossed its cookies today, but did not crash. Neither using Plex for Mac 1.59.1.3398, Plex for Apple TV 8.13, nor Plex for iOS 8.13, were we able to watch any OTA Live TV. (The Apple TV & iOS HDHomeRun apps functioned properly.)
Restarting the Apple TV twice did not resolve the inability to watch OTA Live TV.
At 10:51pm PST Plex for Mac > Activity claimed that several more than eleven (>>11) session threads were in progress.
At 10:52pm PST Live TV > DVR Schedule depicted only two shows finishing recording, both of which were scheduled to finish at 9:00pm PST.
While, restarting the PMS for Mac host appeared to restore OTA Live TV watching, it may be significant that the second of the two shows scheduled to finish at 9pm PST was no longer shown in the Live TV > DVR Schedule:
Upon further inspection of the PMS for Mac host files, it appears that both of the 8pm PST – 9pm PST ceased being recorded at ~8:21pm PST:
.
.
I have separately messaged a PMS log files ZIP directly.
The only content of our Plex library is now and always has been files created by PMS recording OTA Live TV from our HDHomeRun tuner (ie, we have not added any non-PMS-created media whatsoever).
The dedicated 12TB external drive is only used by PMS. The first PMS version installed was well after 1.18, 1.26 perhaps, installed at the end of March 2022, if I recall correctly.
Logs show that the server was stuck handling tune requests - it is possible it was some form of deadlock - I will need to look further into the logs.
I can have a look at the Plex Media Server database and EPG database to try and understand why some recordings ended up as not the episodes you expected
Please shutdown/close Plex Media Server and then go to this folder
/Users/swappletf/Library/Application Support/Plex Media Server/Plug-in Support/Databases/
and copy out these files
com.plexapp.plugins.library.db
com.plexapp.plugins.library.db-wal
com.plexapp.plugins.library.db-shm
tv.plex.providers.epg.cloud-883bf1e1-86d1-4322-8bf9-24cdec3cf471.db
tv.plex.providers.epg.cloud-883bf1e1-86d1-4322-8bf9-24cdec3cf471.db-wal
tv.plex.providers.epg.cloud-883bf1e1-86d1-4322-8bf9-24cdec3cf471.db-shm
The -wal and -shm files may not exist if the databases were closed tidily
Please zip these files and upload the zip to google drive / cloud / dropbox and send me a link by private message
PMS for Mac 1.30.2.6563 Crashed 11 Jan 2023 1:08:09am PST (~8 hours 36 minutes after installation).
