[mythtv-users] mythv 0.27 test packages (future RPM Fusion)

Thu Oct 31 00:56:34 UTC 2013

Has anyone built the SRPM on RHEL6/CENTOS6/SL6? If so, where did you get
QT48? Source? Another repo?

    Thanks,
      --Matt

     --Matt

On Sun, Oct 13, 2013 at 9:43 PM, Monkey Pet <monkeypet at gmail.com> wrote:

>
>
>
> On Tue, Oct 8, 2013 at 4:55 PM, Monkey Pet <monkeypet at gmail.com> wrote:
>
>> On Mon, Oct 7, 2013 at 12:22 PM, Richard Shaw <hobbes1069 at gmail.com>wrote:
>>
>>> On Mon, Oct 7, 2013 at 2:07 PM, John Pilkington <J.Pilk at tesco.net>wrote:
>>>
>>>> On 07/10/13 13:48, Richard Shaw wrote:
>>>>
>>>>> Latest 0.27 source RPM:
>>>>>
>>>>> https://dl.dropboxusercontent.**com/u/34775202/mythtv-0.27-0.**
>>>>> 4.fc19.src.rpm<https://dl.dropboxusercontent.com/u/34775202/mythtv-0.27-0.4.fc19.src.rpm>
>>>>>
>>>>> Includes fixes from git through last Friday.
>>>>>
>>>>
>> Thanks Richard, I loaded it last night.
>>
>
> No big issues seen with 0.27.  the backend was able to record TV shows and
> flag the commericals.  My setup is with a HD homerun recording OTA.
>
> However, I did see one issue, which is as follows.
>
> Oct 13 15:43:31 mythtv abrt-server[1162]: Duplicate: core backtrace
> Oct 13 15:43:31 mythtv abrt-server[1162]: DUP_OF_DIR: /var/tmp/abrt/Python-
> 2013-10-09-02:40:03-17663
> Oct 13 15:43:31 mythtv abrt-server[1162]: Deleting problem directory
> Python-2013-10-13-15:43:28-1157 (dup of Python-2013-10-09-02:40:03-17663)
> Oct 13 15:43:31 mythtv gnome-session[1628]: abrt-applet: repeated problem
> in mythtv-common-0.27-0.3.fc19, not showing the notification
> Oct 13 15:43:32 mythtv abrt: detected unhandled Python exception in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:32 mythtv abrtd: New client connected
> Oct 13 15:43:32 mythtv abrt-server[1178]: Not saving repeating crash in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:33 mythtv abrt: detected unhandled Python exception in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:33 mythtv abrtd: New client connected
> Oct 13 15:43:33 mythtv abrt-server[1184]: Not saving repeating crash in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:41 mythtv abrt: detected unhandled Python exception in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:41 mythtv abrtd: New client connected
> Oct 13 15:43:41 mythtv abrt-server[1338]: Not saving repeating crash in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:42 mythtv abrt: detected unhandled Python exception in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:42 mythtv abrtd: New client connected
> Oct 13 15:43:42 mythtv abrt-server[1344]: Not saving repeating crash in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:42 mythtv abrt: detected unhandled Python exception in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:42 mythtv abrtd: New client connected
> Oct 13 15:43:42 mythtv abrt-server[1350]: Not saving repeating crash in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:43 mythtv abrt: detected unhandled Python exception in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
> Oct 13 15:43:43 mythtv abrtd: New client connected
> Oct 13 15:43:43 mythtv abrt-server[1356]: Not saving repeating crash in
> '/usr/share/mythtv/metadata/Movie/tmdb3.py'
>
> [root at mythtv Python-2013-10-09-02:40:03-17663]# cat backtrace
> request.py:158:handle_status:TMDBRequestInvalid: Invalid id - The
> pre-requisite id is invalid or not found.
>
> Traceback (most recent call last):
>   File "/usr/share/mythtv/metadata/Movie/tmdb3.py", line 278, in <module>
>     main()
>   File "/usr/share/mythtv/metadata/Movie/tmdb3.py", line 272, in main
>     buildSingle(args[0], opts)
>   File "/usr/share/mythtv/metadata/Movie/tmdb3.py", line 50, in buildSingle
>     if getattr(movie, j):
>   File "/usr/lib/python2.7/site-packages/MythTV/tmdb3/util.py", line 143,
> in __get__
>     self.poller.__get__(inst, owner)()
>   File "/usr/lib/python2.7/site-packages/MythTV/tmdb3/util.py", line 67,
> in __call__
>     if not self.apply(req.readJSON(), False):
>   File "/usr/lib/python2.7/site-packages/MythTV/tmdb3/cache.py", line 111,
> in __call__
>     data = self.func(*args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/MythTV/tmdb3/request.py", line
> 119, in readJSON
>     handle_status(data, url)
>   File "/usr/lib/python2.7/site-packages/MythTV/tmdb3/request.py", line
> 158, in handle_status
>     raise status
> TMDBRequestInvalid: Invalid id - The pre-requisite id is invalid or not
> found.
>
> Local variables in innermost frame:
> status: TMDBRequestInvalid('Invalid id - The pre-requisite id is invalid
> or not found.',)
> query: '
> http://api.themoviedb.org/3/movie/73893?api_key=c27cb71cff5bd76e1a7a009380562c62&language=en
> '
> data: {u'status_code': 6, u'status_message': u'Invalid id - The
> pre-requisite id is invalid or not found'}
>
>
>
>>
>>
>>>
>>>>> Thanks,
>>>>> Richard
>>>>>
>>>>
>>>> OK.  Many thanks.  I have el6 i386 rpms built from this installed and
>>>> running on the laptop - but the version number reported is still the
>>>> 317d5b7 of the 0.27 release and the changelog says it's still 0.26.1-2 :-)
>>>>
>>>
>>> Yeah, I'm running both SRPMS out of the same directory structure for
>>> rpmbuild so they're picking up the same ChangeLog but that will be fixed
>>> with the full 0.27 release.
>>>
>>>
>>> I've looked at the specfiles on both machines and am even more confused;
>>>> the vers_string and gitrev for the previous build in f18 are both
>>>> v0.27-1-g5b917e8; today's build in el6 has v0.27-20-g0536d47 and
>>>> v0.27-1-g5b917e8. It looks as if these may be the markers for the
>>>> same-epoch master branch.
>>>>
>>>
>>> Not sure what you mean there... The earlier srpm was v0.27-1 (one commit
>>> from the original v0.27 tag in git) and the ver_string is what is actually
>>> used, the _gitrev is only used when the macro "branch" is set to "master",
>>> so ignore _gitrev. I could actually take this out of the RPM Fusion spec
>>> file since it will never run master but I'm trying to harmonize the RPM
>>> Fusion spec with the mythtv upstream spec.
>>>
>>>
>>> I'm not using mock and a few remains of older builds are still around,
>>>> but I don't see the reported mythfrontend --version in another specfile.
>>>>
>>>> The laptop still uses the old 'Watch Recordings' layout, too, although
>>>> I renamed the old themecache folder, and recordings-ui.xml is the same on
>>>> both boxes.  All rather odd.  But I do appreciate your efforts - and Myth
>>>> seems to be working rather well.
>>>>
>>>
>>> Can't help you there...
>>>
>>> Thanks,
>>> RIchard
>>>
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users at mythtv.org
>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>
>>>
>>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20131030/6dbdf703/attachment.html>