Thanks for the update, but I'm still seeing the same issue :( Does it have anything to do with the hardcoded path mentioned in the logs?
Thanks for the update, but I'm still seeing the same issue :( Does it have anything to do with the hardcoded path mentioned in the logs?
New log
Humm no that path is from the pdb file (debug file that adds line numbers to the logs). That error is from recently added notifications. I'll fix it tomorrow.
I cannot make any notification errors with MySql or MsSqlCe.
What is the behavior you are seeing?
Anyone else having issues with notifications?
Sent from my SM-N900P using Tapatalk
Okay I'm not sure what I did, but after restarting the application a few times it's suddenly started working! Start events still aren't showing up in the application activity view but I do get notifications now! But I'm seeing a problem with the notification string. I have the playing title formatted as '{UserName} is using Plex' and the playing message formatted as 'Watching {Video} on {Player}' but whenever I play something on plex/web or on my iPhone the player name is blank. eg I receive 'moussa.uk is using Plex: Watching Finding Nemo on '.
Thanks for your patience
So I was reviewing the video stats page and I noticed that there is an entry for “speed”. Is this the speed that my server is transcoding the file at? If so, how do I get a value in there? I reviewed a video that was clearly transcoding and the speed was 0.
I've found a few errors that remain in v0.0.0.89 that I'm now using.
I'm not sure if these errors were introduced by recent changes or have been present in older versions as well.
I'm including two picture attachments to illustrate the errors.
This first picture is a screenshot from the main window of PlexNotify, and it shows two episodes of a show being played from start.
PlexNotify incorrectly shows both episodes as being resumed, though that was not the case.
Both episodes have been viewed by the same user before in many tests, so a resume point did exist at this new launch.
But my point is that the resume option was declined, instead choosing to play each video from its beginning.
So these launches should not have been registered as resumptions.
The next picture is a snapshot from the 'Log Of Events' window shortly after the earlier test.
The entries it shows from the above test are almost correct, but if you look closely you'll see some differencies.
The ETA times shown have moved ahead several minutes, and the "has resumed from stop" strings have become "watches"...
And below those entries there are two entries for an episode of "The Big Bang Theory" which I played before going to sleep last night. Note how the event timestamp of both those events are at a little more than twenty minutes before 1 AM, while the ETA time shown is 10:36:36. This means that the ETA was calculated based on the time when the log was displayed, rather than the time when the notification occurred.
Btw: there is also another error in the second picture, as the 'watches' entry is shown as a clean start, even though it was less than a minute from the end of the video. But that is irrelevant here, as this was due to one of the bugs you fixed last night. I don't think this has anything to do with the ETA issue, since that incorrect ETA time was calculated this morning (still night in the US though :D ).
Summary:
The "Log Of Events" shows ETA based on log display time, not original event timestamp.
The "Log Of Events" shows some event activity differently from original notifications of the same events.
The original notifications sometimes shows videos as being resumed even when restarted from beginning.
Best regards: dlanor
I've found a few errors that remain in v0.0.0.89 that I'm now using.
I'm not sure if these errors were introduced by recent changes or have been present in older versions as well.
I'm including two picture attachments to illustrate the errors.
This first picture is a screenshot from the main window of PlexNotify, and it shows two episodes of a show being played from start.
PlexNotify incorrectly shows both episodes as being resumed, though that was not the case.
Both episodes have been viewed by the same user before in many tests, so a resume point did exist at this new launch.
But my point is that the resume option was declined, instead choosing to play each video from its beginning.
So these launches should not have been registered as resumptions.Snap- Improper Resume Notifications.png
The next picture is a snapshot from the 'Log Of Events' window shortly after the earlier test.
The entries it shows from the above test are almost correct, but if you look closely you'll see some differencies.
The ETA times shown have moved ahead several minutes, and the "has resumed from stop" strings have become "watches"...
And below those entries there are two entries for an episode of "The Big Bang Theory" which I played before going to sleep last night. Note how the event timestamp of both those events are at a little more than twenty minutes before 1 AM, while the ETA time shown is 10:36:36. This means that the ETA was calculated based on the time when the log was displayed, rather than the time when the notification occurred.
Btw: there is also another error in the second picture, as the 'watches' entry is shown as a clean start, even though it was less than a minute from the end of the video. But that is irrelevant here, as this was due to one of the bugs you fixed last night. I don't think this has anything to do with the ETA issue, since that incorrect ETA time was calculated this morning (still night in the US though :D ).
Summary:
The "Log Of Events" shows ETA based on log display time, not original event timestamp.
The "Log Of Events" shows some event activity differently from original notifications of the same events.
The original notifications sometimes shows videos as being resumed even when restarted from beginning.
Best regards: dlanor
Your the best dlanor. I will get these fixed asap.
Sent from my SM-N900P using Tapatalk
So I was reviewing the video stats page and I noticed that there is an entry for "speed". Is this the speed that my server is transcoding the file at? If so, how do I get a value in there? I reviewed a video that was clearly transcoding and the speed was 0.
Honestly I have no clue. I know it has something to do with transcoding because if you watch it, it changes as the media plays. I think it's the rate it transcodes at so you can see if you are falling behind and causing buffering. I will put more analytics on this stat. Thinking about it, it's pretty important.
Sent from my SM-N900P using Tapatalk
Honestly I have no clue. I know it has something to do with transcoding because if you watch it, it changes as the media plays. I think it's the rate it transcodes at so you can see if you are falling behind and causing buffering. I will put more analytics on this stat. Thinking about it, it's pretty important.
Sent from my SM-N900P using Tapatalk
Yeah, I'm just not sure why it's blank when I am clearly transcoding. Are you scraping the logs for the info?
The original notifications sometimes shows videos as being resumed even when restarted from beginning.
This my friend has been an ongoing epic struggle with this application and is one of the main reasons why I want to keep it in alpha. Video watch re-starts are not consistent with the API. I have a hard time telling when the video is being re-started.
Yeah, I'm just not sure why it's blank when I am clearly transcoding. Are you scraping the logs for the info?
I dont scrape logs at all. I get everything from the web API.
Alpha v0.0.0.90
- "Enable IP Logging" now properly sets the switch when the settings window is loaded.
- Added additional information to SQL errors.
- Estimated end time will now properly update with the last time the video was viewed instead of the current date and time.
Thanks for the update, but I'm still seeing the same issue :( Does it have anything to do with the hardcoded path mentioned in the logs?
are you still having problems? can you send me your log if you still are?
I have a quick question, ever since I upgraded all is working but when I click on statistics each time I click on a new area down on the lower left it says getting data, it goes up to 389 and it takes about 5 seconds for it to get there, before it used to be pretty quick, is there something I have set wrong that's making it slower? This is on an i7@4ghz with 16gb of ram and it runs on an ssd.
I have a quick question, ever since I upgraded all is working but when I click on statistics each time I click on a new area down on the lower left it says getting data, it goes up to 389 and it takes about 5 seconds for it to get there, before it used to be pretty quick, is there something I have set wrong that's making it slower? This is on an i7@4ghz with 16gb of ram and it runs on an ssd.
This is normal, I am adding an option in the next patch to keep the statistics page active when not visible. This way you dont have to wait for the loading bar.
Alpha v0.0.0.91
- When a users IP is found, it will only be logged once instead of every update.
- Fixed Index out of range exception when recently added items notify.
- Recently added notifications are no longer clickable. (Clicking the notifications was causing a crash)
- Added option to keep the statistics window running in the background once opened. This is disabled be default.
- NOTE: Keeping the stats window open in the background uses extra memory and CPU. It will keep the page it was on when it was closed.
I dont scrape logs at all. I get everything from the web API.
I took a look at some of the other saved watching and it looks like that data is accurate. It shows how far ahead your transcoder session is. Need to be at least 1.0 for the session to work properly.
I'm sorry to report that there is now a new problem with the ETA calculations in version 0.0.0.91 of PlexNotify, which I'm now using.
This error seems to be a direct result of trying to base the ETA on the latest launch of a given video, instead using the oldest launch...
NB: I consider either of these methods to be wrong, but I'll go into my reasons for that near the bottom of this post.
First I'll focus on the current error.
Here's one snapshot from the top of the list in the main window:
As you can see there is no longer any connection between the notification display time (appx 11:07 today Swedish time) and the calculated ETA.
But that ETA is obviously wrong, since it claims that the newly started episode will finish over 3 months ago.
Checking back I find that my brother Peter did start that 'Vikings' episode back then for the first time.
Evidently he now wants to watch the series again, a quarter of a year later, which should result in completely independent new ETA calculations.
Here is another snapshot from the "Log Of Events" for the same entries made today:
This shows that the ETAs in the log are consistent with those shown in main screen, both being calculated the same wrong way.
And here is another main screen snapshot from some stuff Peter played earlier today:
This one is odd, in that the ETA calculations are inconsistent. One reaches 90 minutes into the past, and the other one less than 4 minutes...???
Now on to the main point of this post, which is to say that I consider it wrong to reach for either the oldest or the latest log entry for a video in order to base ETA calculations on those timestamps. Every event should be considered as independent of all others when it comes to ETA. So the ETA calculated for any given playback event should be based ONLY on the timestamp of that particular event and the remaining playing time of that media file. To involve either earlier or later events in that calculation invalidates the log. Instead of a log it becomes a collection of endlessly running time estimates, subject to update whenever a new entry is made for the same video as in an old log entry.
In order to be useful as a log, I need to be able to compare the ETA that was calculated at the time of the event with the real timestamp where the video either finished normally or was turned off by the user. That comparison is important for my evaluation of possible server/client problems, and this comparison becomes impossible if the ETA of past log entries are adjusted each time a video is restarted. So each ETA value should be calculated once only, at the time when the event is registered, and based only on remaining playtime added to the current timestamp. If that doesn't match how the events are stored, then the ETA calculations may need to be repeated at display time, but they should still only calculate the simple sum of remaining playtime when the event occurred plus the timestamp of the event itself, involving no other events.
Sorry if I overstated my case a bit above, but I wanted to make my meaning absolutely clear... ;)
Best regards: dlanor
I just became aware of two more problems with the current PlexNotify.
In the submenu Settings > 'Notify Text' I can no longer see the syntax info line at the bottom of the screen clearly, as only its top half is visible, the rest being cut off by some window edge effect. This is in Win7 with its new window border sizes, so you may need to take that into account in your coding.
I noticed that problem in trying to check for causes of the other problem, which is that I no longer get {player} or {platform} displays.
It was in trying to check the available syntax that I noticed the first problem mentioned above, as the info line was hard to read.
But I did see that both {player} and {platform} are supposedly still supported, and yet I don't see any such strings in notifications or logs.
You can see this for yourself in the logs I posted earlier, where there are sequences like "()" and "( on )"
Those in fact represent template expansions of "({Player})" and "({Player} on {Platform})", none of which are currently working.
This used to work fine in older versions of PlexNotify, but I'm not sure when this ability was lost.
Best regards: dlanor
I have also experienced the bug detailed above, where the syntax info line is barely showing in windows 7. I also have some trouble with the Notify Texts where the template "{UserName} is watching "{Video}". Estimated done {EndTime} (via {Player}.) Plot {Summary}" shows nothing for {Player} and {Summary}. {UserName} and {Video} and {EndTime} works fine. I recently changed this to include {Player} and {Summary}, so I figure that means something has gone wrong since I first set ut the original template.
I also would prefer email support and other new functions before the music support, since I won't be using that anyway.
Alpha v0.0.0.92
- Video cache no loner caches to the Database. It now caches to the Plex Notify application data directory.
- This will fix some tokens not appearing.
