Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CountryBumkin]

After the problems with version .139 and .140 I had to reimport my Library. When I did this it wiped out the data/dates in "Last Played". I use this tag in Theater View to indicate which episodes in a TV Series I have already viewed. I also like to sort my Movies by those I have "not watched" in a while (sort by last played (z-a)).
Anyways, the dates are gone and MC will not let me manually enter a date.
If there is no good reason to lock this field, can someone at JRiver make this field editable?
Thanks.

[MrHaugen]

I've updated the Number Plays lots of times, but you can't do this without an expression field I think.
For example create a field called "Date Watched Update", select Calculated data and enter this as an expression: "=[Date Watched]"
You should then be able to write the date in the new field, and the original field will be updated. Probably

[CountryBumkin]

Thanks MrHaugen. Do you know why JRiver folks would want to prevent someone from entering/changing data that field?

I would like to be able to edit in Standard View>Video>Files. If you click on the Last watched field and "F2" you get a selection box which will let you pick a "bank" which then changes the field (from whatever the date last played was) to "never played", but you can not enter a date if the field is empty or change a date if there is one already in the field.

This seems like a harmless request and, I think, would be useful to the end user.

[MrHaugen]

I agree that these locked fields would be good to open up for the more techie user like us. But I think that JRiver have concerns about normal users and what could happen if people for example suddenly makes huge changes to stuff like this, and there are all sorts of views and smartlists and so on tied to it. And the logical reason that not many needs to change them, as it's all done automatically "under the curtain". I certainly understand that some needs to change this values from time to time, but I do not know if the best solution is to just open up all these fields. Perhaps they could be open somehow, but that is would take some effort to do?

[rjm]

I'd like to see an expert mode, perhaps enabled in Options\General\Features, that made all fields editable including Removable and Image File.

[rick.ca]

Do you know why JRiver folks would want to prevent someone from entering/changing data that field?

In general, it's not good practice to allow a system-maintained field to be edited in exactly the same way as user data fields. In this particular case, there would be no harm in providing some kind of override—as that would ensure it's not being changed by accident or misunderstanding. The trick of using an expression field as a means to change the values seems to be an accident of design rather than intentional, but it does work. It's also effective in ensuring it's available only to those who know what they're doing.

Having said that, I don't know what I'm doing when it comes to changing [Last Played]. I can't figure out how to provide the date value necessary to produce a desired date. One of the things on my list to ask MrC...

[CountryBumkin]

Having said that, I don't know what I'm doing when it comes to changing [Last Played]. I can't figure out how to provide the date value necessary to produce a desired date. One of the things on my list to ask MrC...

I see what you mean. I followed MrHaugen's suggestion and created a new field called "Date Watched", but no matter what data (date) I put into the field, I always get 12/31/1969.

[MrHaugen]

Are not all the date fields in MC based on this integer value starting some hundred years ago? I remember I tried to figure out this for the Year field, and I had to find the 0 and then add 365 for each year to get the correct one. Excel has a function to convert dates to this number I think.

I would really like it if MC was able to pick up some common date syntax here though. It's hell to operate with strings of numbers.

[glynor]

MC uses Excel-style dates internally and in the file tags.  Try one of those.

There are converters to Excel style online.  It is like Unix time, but with a different epoch.

[rick.ca]

MC uses Excel-style dates internally and in the file tags.

I assume the number used is that returned by ConvertDate([Last Played]) (e.g., now it's 41034.738194). The problem seems to be the 'trick' of using an expression column doesn't work when the value has been converted. I'm almost convinced it's just not possible to change [Last Played].

[MrC]

I'll give a teaser.  It can be changed just fine.

[Lasse_Lus]

i use this math(now()-25569)*86400-[timezone])

= "now" - 1970-01-01 * seconds per 24 h - "my timezone"

[MrC]

Nice, you got it.  To set a specific date, use ConvertDate() instead of Now().  For example, to set the date to Jun 8th, 2011, for the PST timezone (-7 hours from GMT):

=math((ConvertDate(6//8//2011)-25569)*86400-(-7*60*60))

[rick.ca]

To set a specific date, use ConvertDate() instead of Now().  For example, to set the date to Jun 8th, 2011, for the PST timezone (-7 hours from GMT):

Sorry, you don't get to leave me twisting in the wind and then claim this is a complete answer!

If one has last played values for a set of files and they want to set [Last Played] to those values, they'll want to use another field as input rather than entering each one separately. And then this is not just a matter of entering the date to get the value, but also copying the value to the expression column to update [Last Played]. The former might be imported or calculated, and the latter set with a =[My Calculated Date Values] edit. So a significant question remains: How is the time zone adjustment varied to take into account Daylight Savings Time?

Lasse_Lus, is your [timezone] an expression field that does that?

Also, it seems all the results are out by a few minutes. Is that a precision issue I'm not dealing with correctly?

[Lasse_Lus]

..your [timezone] an expression field that does that?

well, it just a global variable that i change twice a year to get time+(summertime or viceversa included).

Also, it seems all the results are out by a few minutes. Is that a precision issue I'm not dealing with correctly?

yes, sometimes there is a discrepancy, i tried to solve that a long time ago (but i could not), but there must be some decimal issue 

[rick.ca]

Thanks. After being teased, it's nice to know I've got MrC on two good hooks.

BTW, I don't have any particular problem with play stats I need to resolve—I'm just curious how this works. I have started periodically saving my data to a history list field as '[Last Played] #[Number Plays]'. This gives me a picture of plays vs. time, and also serves as a backup. I thought it might come in handy to know how to restore the current data from the history. I'm not sure why—maybe to roll-back the data for a period MC was left playing without me listening to it.

[CountryBumkin]

Can you provide some step-by-step directions to set up a new field (Date Watched) in the Standard View (in video>files) where I can enter a date (or even a "Yes" or "No" would be fine) for each movie or show?

I made several attempts (following the posts here) to create an expression field called Date Watched but still can't get this right.

Thanks

[MrC]

I believe some of the discrepancy is due to how MC adjusts the date/times fractionally to help it identify year-only, or year-month, or year-month-day.  There are some precise values you can enter, and MC will display only a year.  Bias that number by a small amount, and it displays a full date.  It adds some internal fudge-factor.  It also biases the date for file-friendly time stamp values.  While it won't be a good reference time keeper, it is sufficient for user's purposes.

A discrepancy may also occur because the formula is not adjusting for DST in affect at the time.  You'd have to adjust this yourself (via the timezone bias, for the DST in affect at the time) as there is no public functionality to manage this.

You can create a new Date field, call it [My Last Played].  Then, enter your desired date there, and modify the formula to be:

  math(([My Last Played,0]-25569)*86400-(-7*60*60))

and use that to assign to [Last Played]:

  =math(([My Last Played,0]-25569)*86400-(-7*60*60))

[MrHaugen]

If I were you, I think I would use the Number Plays field instead of this date. Drop the whole date thing. It's just to annoyingly difficult to use Number plays will work just as well, as long as you don't need the specific date for views or something.

Make a library field that contains this Expression: =[Number Plays]

When you add number values to this new field, the value will be copied to the Number Plays field.

[rick.ca]

A discrepancy may also occur because the formula is not adjusting for DST in affect at the time.  You'd have to adjust this yourself (via the timezone bias, for the DST in affect at the time) as there is no public functionality to manage this.

I was working on an expression to do this when I realized ConvertDate() doesn't seem to be working (it returns nothing). Can someone confirm this, or that I'm losing my mind (quite likely after this exercise)?

[MrC]

Forgot to double-up on the forward slashes?

[rick.ca]

Forgot to double-up on the forward slashes?

That's it. Thanks.

But I didn't forget, and this seems more MC is losing it's mind. The purpose of the function is to convert a 'human readable' date to the value used internally. And that's all it does. Why should it be necessary to convert the input it's supposed to be converting? In any case, it seems the wiki entry should be updated to explain this.

[MrC]

It's the nature of computer languages - certain characters are reserved, even when sometimes they're inconvenient to be so.

You can also use /# #/ to escape escaping:

  ConvertDate(/# 1/3/2002 #/)

or use a different separator:

    ConvertDate(1-3-2002)

[JustinChase]

If the original request was made simply to populate the field with something (the value is not important), you could just play the file, skip right to the end and MC will enter a date for you.

For a few files, this is probably faster/easier than all the 'trickery' discussed above.  However, if the date does matter, or you have hundreds of files to fix, this suggestion would be more tedious. 

I have done this for dozens of files that I watched while connected to a "read only" library, and it goes pretty quickly, since as soon as the file starts playing, you can just click on the very end of the progress bar to skip to the end.  Or, temporarily set the skip forward time (in options) to just under the length of the episodes you wish to amend, so you can just hit the right arrow button to skip to nearly the end.  I believe watching more than 1/2 way thru a video still 'counts' as being watched, so you don't have to watch every second to get this date populated.

I guess it's a matter of "pick your poison"

[rick.ca]

A discrepancy may also occur because the formula is not adjusting for DST in affect at the time.  You'd have to adjust this yourself (via the timezone bias, for the DST in affect at the time) as there is no public functionality to manage this.

This was the best I could come up with... 

Code: [Select]

If(IsEmpty([Date.entry]), , Math((ConvertDate([Date.entry])-25569)*86400 + Math(Math(8 - Math(/
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//11//2007) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//04//2007) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//09//2008) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//02//2008) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//08//2009) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//01//2009) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//14//2010) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//07//2010) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//13//2011) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//06//2011) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//11//2012) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//04//2012) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//10//2013) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//03//2013) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//09//2014) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//02//2014) + 2/24)), 1, 0), 0) + /
If(Compare(ConvertDate([Date.entry]), >=, Math(ConvertDate(03//08//2015) + 2/24)), If(Compare(ConvertDate([Date.entry]), <=, Math(ConvertDate(11//01//2015) + 2/24)), 1, 0), 0)/
)) * 3600)))
Not very elegant, but it seems to work for the range of [Last Played] I have, and for the next three years. I put this in an expression field [Date.value]. Now I can populate [Date.entry] with dates and then just enter '=[Date.value]' in a [Last Played] expression column to update [Last Played] for all the files at once—without concern for DST adjustments.

[MrC]

Now that's dedication!

For fun, try this value for setting the Last Played date:

  1293868800

For bonus fun, here's a little perl program I just wrote that will convert input date/times into the necessary seconds.  You can see how it handles DST correctly for the local time zone rules in effect (and these are quite complicated):

$ cat | perl -MPOSIX -MTime::Local -ne 'm-(\d+)/(\d+)/(\d+)(?: (\d+):(\d+))?-; $t=timelocal(0,$5|0,$4|0,$2,$1-1,$3-2000); print "$t = " . strftime("%c", localtime($t)) . "\n";'
5/2/2012
1335942000 = Wed May  2 00:00:00 2012
5/2/2012 18:15
1336007700 = Wed May  2 18:15:00 2012
3/11/2012 1:59
1331459940 = Sun Mar 11 01:59:00 2012
3/11/2012 2:00
1331460000 = Sun Mar 11 03:00:00 2012
3/10/2013 1:59 
1362909540 = Sun Mar 10 01:59:00 2013
3/10/2013 2:00
1362909600 = Sun Mar 10 03:00:00 2013

[rick.ca]

For fun, try this value for setting the Last Played date:

Right. I was thinking of handing that, but I decided it would be easier just to never play anything that's going to end within the first two minutes of a new year.

For bonus fun, here's a little perl program I just wrote that will convert input date/times into the necessary seconds.  You can see how it handles DST correctly for the local time zone rules in effect (and these are quite complicated):

Cool. Hopefully, we'll you'll be able to do that in MC some day.

[CountryBumkin]

If the original request was made simply to populate the field with something (the value is not important), you could just play the file, skip right to the end and MC will enter a date for you.

For a few files, this is probably faster/easier than all the 'trickery' discussed above.  However, if the date does matter, or you have hundreds of files to fix, this suggestion would be more tedious. 

I have done this for dozens of files that I watched while connected to a "read only" library, and it goes pretty quickly, since as soon as the file starts playing, you can just click on the very end of the progress bar to skip to the end.  Or, temporarily set the skip forward time (in options) to just under the length of the episodes you wish to amend, so you can just hit the right arrow button to skip to nearly the end.  I believe watching more than 1/2 way thru a video still 'counts' as being watched, so you don't have to watch every second to get this date populated.

I guess it's a matter of "pick your poison"

I like simple solutions (especially so I don't have to go nuts figuring out how to program). Your suggestion gets the job done.

I just don't see why this needs to be so hard. JRiver should allow editing of this field and should make it work by just letting User put in a real date (have MC do the converting internally). And, why lock down the "last Played" field - what harm could be done even if a User mistakenly adds bad data in this field?

[JustinChase]

I like simple solutions (especially so I don't have to go nuts figuring out how to program). Your suggestion gets the job done.

Glad I could help   I'm also happy to know I'm not the only one that thinks learning a new language to do simple things isn't always the best way 

[glynor]

I just don't see why this needs to be so hard. JRiver should allow editing of this field and should make it work by just letting User put in a real date (have MC do the converting internally). And, why lock down the "last Played" field - what harm could be done even if a User mistakenly adds bad data in this field?

+1

It would work for me even if it was as simple as this:  Allow the user to modify [Number of Plays].  When [Number of Plays] increases, bump the [Last Played] field to the current date/time.

That would solve 99% of the times when I need to "fix" one of these fields.  It is almost always just that I want to mark a particular episode as played that didn't get marked played properly for a variety of esoteric reasons:

1. Connecting to a remote read-only library for one reason or another.
2. MC crashed or something (or I shut the server down) before the client had a chance to update the [Number of Plays] and [Last Played] fields.
3. Playing a bunch of videos via some other non-MC application (in my case, almost always AirVideo on my iDevices).
4. Playing a bunch of videos using MC on a laptop using a local library, because I'm "on the road" on a trip somewhere.  See also this awesome idea.

In all these cases, I often just want to "bump" the items in my main MC library to essentially "mark them as watched".  I don't particularly care about the precise date/time they were watched (though others might disagree), I just want them to be marked as "done" so that when we come back, we know where we "left off" in a series.

[CountryBumkin]

Exactly!

[MrHaugen]

Very good points Glynor. I also travel with some episodes on my phone now and then, and it's a little annoying that this is not something that you can do with just a push of a button in either standard or Theater View.

[rick.ca]

It would work for me even if it was as simple as this:  Allow the user to modify [Number of Plays].  When [Number of Plays] increases, bump the [Last Played] field to the current date/time.

Unfortunately, that would be extremely annoying for those who may want change [Number of Plays] without changing [Last Played].

I have no objection to these fields being editable, but that's only because they're not critically important to me. There is potential value in protecting the integrity of a system-maintained field. Maybe an effective compromise is to allow an edit after a warning is dismissed. A 'protected edit' might be a useful edit-type for the user to apply to any field. Such fields would allow an edit, but only after a warning: "This is a protected field. Do you wish to proceed with editing?"

[glynor]

Unfortunately, that would be extremely annoying for those who may want change [Number of Plays] without changing [Last Played].

Hadn't considered that.  

Well, I don't see any particular reason that they shouldn't both be directly editable, but I often fall on that side of the coin in these discussions... Other than maybe that coding the error logic on the [Last Played] field (which would have to be different from [Date] which allows you to enter just a year and other such nonsense) would take Matt a little bit of time he doesn't feel like spending.  The date parsing should be basically all done, with the stuff MC already has.

In any case, I personally wouldn't care if it didn't touch the [Last Played] field at all and just left it blank when you bump the [Number of Plays] field.  I go by [Number of Plays] typically and only glance at the [Last Played] occasionally.  So, if we only get one, that would be my top priority.

In fact, it might be kind of nice to have [Last Played] stay blank when you bump the [Number of Plays] field, as it would serve as a sort-of "indicator" that you bumped it manually.  I only really suggested the alternative because I thought... Two birds.  Plus, it is also possible that there is logic elsewhere in MC that depends on the fact that you can't have a zero [Last Played] with a non-zero [Number of Plays] and vice-verse (weird little buggy fear).

One other thing that would be handy is the ability to quickly reset them back to zero (and this I don't think would go foul of your desire, Rick)...  The other major reason I find the need to occasionally tweak the [Number of Plays] field is when I "check through" a video file (looking at quality, completeness, and checking for corruption).  If I'm not careful, this ends up incrementing the [Number of Plays].  You can fix it if you remove it from the library and re-import, of course, but that's a sledgehammer approach... What if you already spent a while tagging it?  Then you'd have to edit the JRSidecar manually instead of just deleting it...  And the process is annoying anyway, with the deleted items database and all.

Editing them both would be good.

[rick.ca]

In any case, I personally wouldn't care if it didn't touch the [Last Played] field at all and just left it blank when you bump the [Number of Plays] field.

I understand that would make sense in the situation you describe, but it would still be a problem for those who have some other reason to change [Number Plays] and don't want to change or lose [Last Played]. I think allowing them to be edited independently with an appropriate warning is a better solution.

[glynor]

I understand that would make sense in the situation you describe, but it would still be a problem for those who have some other reason to change [Number Plays] and don't want to change or lose [Last Played].

Unless you were just agreeing there, I think you read my comment backwards (or wrong anyway).  I was agreeing with you.  By "leave it blank" I was referring to my common use-case explained above.  I really meant "leave it alone".  Like I said, I hadn't considered that point when I made my initial suggestion.

My main point in that paragraph was that if JRiver is willing to make them editable in some limited fashion, but we are unlikely to get both editable independently for whatever reason, the ability to edit [Number of Plays] manually is far more important to me than messing with [Last Played] (which I'd almost never do in practice).  That's all I meant.

(I re-read that paragraph and it was written all confusingly.  Sorry.)

[DoubtingThomas]

Glad I could help   I'm also happy to know I'm not the only one that thinks learning a new language to do simple things isn't always the best way 

Where is the "Like" button ?