I see this error in the logs often, and so was wondering if there's something that can be done to fix it? Most of what I found on the internet talks about resolving it for Linux, but not sure how to do this on a Mac
2015-10-02 21:09:27.955986 W [1939/3343] CoreContext mythcorecontext.cpp:264 (Init) - This application expects to be running a locale that specifies a UTF-8 codeset, and many features may behave improperly with your current language settings. Please set the LC_ALL or LC_CTYPE, and LANG variable(s) in the environment in which this program is executed to include a UTF-8 codeset (such as 'en_US.UTF-8').
This is just a warning; not an error. Are you seeing some kind of problem that you can attribute to this factor? (On my system, QT appropriately sets the locale and language and this shows a couple of lines below this warning in each of the logs.)
I have just recently noticed that all of my recordings are dated 1 day ahead of when they were recorded. The date code in the recording's filename is always 1 day ahead, so I am wondering if this would cause this?
leejk wrote:I have just recently noticed that all of my recordings are dated 1 day ahead of when they were recorded. The date code in the recording's filename is always 1 day ahead, so I am wondering if this would cause this?
Starting with 0.26, Myth converted to use UTC for date/time information. This avoids any issues in localities that switch to/from Daylight Savings Time.
So, if you want to avoid the 'problem', just move to England!
Can't move to England, but I've always enjoyed my visits
Is it possible that somehow MythTV thinks I'm in another timezone? The system time is right on the machine. These timestamps in the recording filenames are causing me an issue with some post process scripting I'm working on. I suppose I could -1, but ideally I'd like to figure this one out.
So after some more digging, my problem appears to be the UTC time thing. I don't understand the logic in using that, since everything I record is in the same timezone I live, so why they went to UTC time for everything I don't understand. So in my script I'm now using the 'originalairdate' field from the recorded table. It seems to be the ONLY date that is not in UTC time.
Here's the overview of it all; perhaps I'm going about it the wrong way:
I use an OTA antenna with HDHomerun tuner. I use Schedules Direct for the guide data. Half the time, SD does not proved season & episode numbers for the show. I transcode everything Myth records using fmpeg and copy it over to a NAS, in order to watch it later using KODI. In order for KODI to recognize it correctly, season and episode info must be in the filename. As a work around for the missing guide data, I'm using FileBot in my script to retrieve that needed info from the air date.
It's strange that MythTV uses the same TVDB site as the FileBot utility, but yet it does not pull the season and episode info. Seems kinda broke to me, but apparently it only uses that site to pull other metadata.
leejk wrote:So after some more digging, my problem appears to be the UTC time thing. I don't understand the logic in using that, since everything I record is in the same timezone I live, so why they went to UTC time for everything I don't understand. So in my script I'm now using the 'originalairdate' field from the recorded table. It seems to be the ONLY date that is not in UTC time.
Here's the overview of it all; perhaps I'm going about it the wrong way:
I use an OTA antenna with HDHomerun tuner. I use Schedules Direct for the guide data. Half the time, SD does not proved season & episode numbers for the show. I transcode everything Myth records using fmpeg and copy it over to a NAS, in order to watch it later using KODI. In order for KODI to recognize it correctly, season and episode info must be in the filename. As a work around for the missing guide data, I'm using FileBot in my script to retrieve that needed info from the air date.
It's strange that MythTV uses the same TVDB site as the FileBot utility, but yet it does not pull the season and episode info. Seems kinda broke to me, but apparently it only uses that site to pull other metadata.
You might want to reconsider your approach somewhat. One of Myth's developers created a python script to export a recording so that it is suitable to use a video in Myth's Videos side. Which is very similar to what you want to do.
I believe the general idea is that you transcode the recording and then use mythvideexport.py to copy it to another location with a file name formatted according to your specs.
BTW, Myth bundles a slightly modified version of ffmpeg internally so you didn't have to install another copy.
leejk wrote:... so why they went to UTC time for everything I don't understand. So in my script I'm now using the 'originalairdate' field from the recorded table. It seems to be the ONLY date that is not in UTC time...
I recall that there was a small group of users that missed recording twice a year
(when Daylight Savings Time went on and off.) Seems that there was also an
issue with European users that has systems that somehow spanned time zones.
At least my system always displays the correct time although I use mythfrontend,
not KODI. I can't tell if you're seeing the wrong time in KODI only.