Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

"Migrated" recordings from 0.24 won't stream via HLS

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


Spam1 at pontoppidan

May 29, 2012, 12:36 AM

Post #1 of 14 (1517 views)
Permalink
"Migrated" recordings from 0.24 won't stream via HLS

During this weekend I finally chose to reinstall my backend - moving from
an old Fedora install to MythBuntu. For different reasons I decided to go
against recommendations and not move the entire database. I only
transferred my recordings following this guide
http://www.mythpvr.com/mythtv/tips/migrate-recordings.html.

From a normal frontend the recordings are playing fine, but HLS doesn't
seem to work - I try to stream to Torc for IOS, but the "prepare stream"
stays at 0%. If I make a new recording it streams fine so I'm guessing some
new fields in the recordings table are missing? Is there any way to add the
missing info (if my assumption is correct) to the database?


seven at seven

May 29, 2012, 3:40 AM

Post #2 of 14 (1478 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

On 29 May 2012 17:36, Thomas Pontoppidan <Spam1 [at] pontoppidan> wrote:

> During this weekend I finally chose to reinstall my backend - moving from
> an old Fedora install to MythBuntu. For different reasons I decided to go
> against recommendations and not move the entire database. I only
> transferred my recordings following this guide
> http://www.mythpvr.com/mythtv/tips/migrate-recordings.html.
>
> From a normal frontend the recordings are playing fine, but HLS doesn't
> seem to work - I try to stream to Torc for IOS, but the "prepare stream"
> stays at 0%. If I make a new recording it streams fine so I'm guessing some
> new fields in the recordings table are missing? Is there any way to add the
> missing info (if my assumption is correct) to the database?
>
>
>
Have you created the Streaming Storage Group?

There are some other troubleshooting step below

http://www.fecitfacta.com/blog1/torc/

and the official torc for ios user groups are here

http://groups.google.com/group/torc-for-ios

Cheers,

Anthony


michael at thewatsonfamily

May 29, 2012, 4:06 AM

Post #3 of 14 (1477 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

On 29/05/2012 5:36 PM, Thomas Pontoppidan wrote:
> During this weekend I finally chose to reinstall my backend - moving
> from an old Fedora install to MythBuntu. For different reasons I
> decided to go against recommendations and not move the entire
> database. I only transferred my recordings following this guide
> http://www.mythpvr.com/mythtv/tips/migrate-recordings.html.
>
> From a normal frontend the recordings are playing fine, but HLS
> doesn't seem to work - I try to stream to Torc for IOS, but the
> "prepare stream" stays at 0%. If I make a new recording it streams
> fine so I'm guessing some new fields in the recordings table are
> missing? Is there any way to add the missing info (if my assumption is
> correct) to the database?
>
>
Have you tried rebuilding the seek tables for the existing recordings?

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jyavenard at gmail

May 29, 2012, 4:24 AM

Post #4 of 14 (1475 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

On 29 May 2012 20:40, Anthony Giggins <seven [at] seven> wrote:
> Have you created the Streaming Storage Group?

never set that one..
works just fine
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


seven at seven

May 29, 2012, 4:42 AM

Post #5 of 14 (1472 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

On 29 May 2012 21:24, Jean-Yves Avenard <jyavenard [at] gmail> wrote:

> On 29 May 2012 20:40, Anthony Giggins <seven [at] seven> wrote:
> > Have you created the Streaming Storage Group?
>
> never set that one..
> works just fine
> _______________________________________________
>


Opps I didn't realise this was optional

(*Optional*) Set up a “Streaming” storage group (streaming content will
default to ~/.mythtv/streaming)

I guess this would depend on how much space is allocated to your /home

I guess the best test is to try it from *http://IPOfYourBackend:6544/

Cheers,

Anthony
*


Spam1 at pontoppidan

May 29, 2012, 5:02 AM

Post #6 of 14 (1471 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

2012/5/29 Michael Watson <michael [at] thewatsonfamily>

> On 29/05/2012 5:36 PM, Thomas Pontoppidan wrote:
>
>> From a normal frontend the recordings are playing fine, but HLS doesn't
>> seem to work - I try to stream to Torc for IOS, but the "prepare stream"
>> stays at 0%. If I make a new recording it streams fine so I'm guessing some
>> new fields in the recordings table are missing? Is there any way to add the
>> missing info (if my assumption is correct) to the database?
>>
>>
>> Have you tried rebuilding the seek tables for the existing recordings?
>

Didn't think of that - I haven''t experienced the "usual" symptoms like
fast forwarding etc not working. But I will give it a shot tonight.

Thanks for the tip!


Spam1 at pontoppidan

May 29, 2012, 5:08 AM

Post #7 of 14 (1476 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

2012/5/29 Anthony Giggins <seven [at] seven>

> I guess the best test is to try it from *http://IPOfYourBackend:6544/*
>

Thanks for the tips. The problem is only related to HLS in combination with
migrated recordings - not HLS or Torc for IOS generally. New recordings
(recorded after the reinstall) stream just fine both using the link and
Torc for IOS.

I will try repairing the seektable as suggested by Michael Watson.


Spam1 at pontoppidan

May 29, 2012, 11:06 AM

Post #8 of 14 (1463 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

2012/5/29 Michael Watson <michael [at] thewatsonfamily>

> On 29/05/2012 5:36 PM, Thomas Pontoppidan wrote:
>
>> During this weekend I finally chose to reinstall my backend - moving from
>> an old Fedora install to MythBuntu. For different reasons I decided to go
>> against recommendations and not move the entire database. I only
>> transferred my recordings following this guide
>> http://www.mythpvr.com/mythtv/**tips/migrate-recordings.html<http://www.mythpvr.com/mythtv/tips/migrate-recordings.html>
>> .
>>
>> From a normal frontend the recordings are playing fine, but HLS doesn't
>> seem to work - I try to stream to Torc for IOS, but the "prepare stream"
>> stays at 0%. If I make a new recording it streams fine so I'm guessing some
>> new fields in the recordings table are missing? Is there any way to add the
>> missing info (if my assumption is correct) to the database?
>>
>>
>> Have you tried rebuilding the seek tables for the existing recordings?
>

I tried rebuilding the seektable for a recording but no luck:-( In the
backend log this is all I can find:

[code]May 29 19:59:39 Mythbackend mythbackend[6633]: W HTTPLiveStream
httplivestream.cpp:82 (run) HLS(): Command '/usr/bin/mythtranscode --hls
--hlsstreamid 3 --verbose general --loglevel info --syslog local7' returned
255[/code]


mtdean at thirdcontact

May 29, 2012, 12:57 PM

Post #9 of 14 (1458 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

On 05/29/2012 03:36 AM, Thomas Pontoppidan wrote:
> During this weekend I finally chose to reinstall my backend - moving
> from an old Fedora install to MythBuntu. For different reasons I
> decided to go against recommendations and not move the entire
> database. I only transferred my recordings following this
> guide http://www.mythpvr.com/mythtv/tips/migrate-recordings.html.

Yes. Google should be kicked off the Internet for allowing that
ancient, outdated, incorrect, can-corrupt-the-db-data (as it can
completely break your character encoding) post to be #1.

> From a normal frontend the recordings are playing fine, but HLS
> doesn't seem to work - I try to stream to Torc for IOS, but the
> "prepare stream" stays at 0%. If I make a new recording it streams
> fine so I'm guessing some new fields in the recordings table are
> missing? Is there any way to add the missing info (if my assumption is
> correct) to the database?

Best solution is to do a proper restore of your complete pre-upgrade
database and let MythTV Do The Right Thing.

If you decide you want to waste hours re-configuring everything for no
benefit, at least do a proper partial restore:
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
(and take note of
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_when_upgrading_MythTV
).

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


Spam1 at pontoppidan

May 30, 2012, 12:03 AM

Post #10 of 14 (1455 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

2012/5/29 Michael T. Dean <mtdean [at] thirdcontact>

> On 05/29/2012 03:36 AM, Thomas Pontoppidan wrote:
>
>> During this weekend I finally chose to reinstall my backend - moving from
>> an old Fedora install to MythBuntu. For different reasons I decided to go
>> against recommendations and not move the entire database. I only
>> transferred my recordings following this guide
>> http://www.mythpvr.com/mythtv/**tips/migrate-recordings.html<http://www.mythpvr.com/mythtv/tips/migrate-recordings.html>
>> .
>>
>
> Yes. Google should be kicked off the Internet for allowing that ancient,
> outdated, incorrect, can-corrupt-the-db-data (as it can completely break
> your character encoding) post to be #1.


Well, I won't blame Google - after all it was my decision to not follow
official directions:-)


> From a normal frontend the recordings are playing fine, but HLS doesn't
>> seem to work - I try to stream to Torc for IOS, but the "prepare stream"
>> stays at 0%. If I make a new recording it streams fine so I'm guessing some
>> new fields in the recordings table are missing? Is there any way to add the
>> missing info (if my assumption is correct) to the database?
>>
>
> Best solution is to do a proper restore of your complete pre-upgrade
> database and let MythTV Do The Right Thing.
>

Looking back that is probably what I *should* have done, but I am not sure
I'm up for that now - I spent most of a day setting up the new database,
mostly because I wasn't satisfied with the old setup (non-standard
keybindings, bad tuner setup, flawed channel lists etc.). Going back would
require me to do it all over again:-)


> If you decide you want to waste hours re-configuring everything for no
> benefit, at least do a proper partial restore:
> http://www.mythtv.org/wiki/**Database_Backup_and_Restore#**
> Partial_restore_of_a_backup<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup>(and take note of
> http://www.mythtv.org/wiki/**Database_Backup_and_Restore#**
> Partial_restore_when_**upgrading_MythTV<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_when_upgrading_MythTV>).
>

I already did reconfigure the entire setup and according to the links I
would need to do some preparation on the old setup - obviously not possible
now that the system is already upgraded:-(

Guess I will have a closer look at the tables while I consider the
"complete restore" option:-(


mtdean at thirdcontact

May 30, 2012, 7:11 AM

Post #11 of 14 (1438 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

On 05/30/2012 03:03 AM, Thomas Pontoppidan wrote:
> 2012/5/29 Michael T. Dean
>> On 05/29/2012 03:36 AM, Thomas Pontoppidan wrote:
>>
>>> During this weekend I finally chose to reinstall my backend - moving from
>>> an old Fedora install to MythBuntu. For different reasons I decided to go
>>> against recommendations and not move the entire database. I only
>>> transferred my recordings following this guide
>>> http://www.mythpvr.com/mythtv/tips/migrate-recordings.html
>>> .
>>>
>> Yes. Google should be kicked off the Internet for allowing that ancient,
>> outdated, incorrect, can-corrupt-the-db-data (as it can completely break
>> your character encoding) post to be #1.
>
> Well, I won't blame Google - after all it was my decision to not follow
> official directions:-)
>
>
>> From a normal frontend the recordings are playing fine, but HLS doesn't
>>> seem to work - I try to stream to Torc for IOS, but the "prepare stream"
>>> stays at 0%. If I make a new recording it streams fine so I'm guessing some
>>> new fields in the recordings table are missing? Is there any way to add the
>>> missing info (if my assumption is correct) to the database?
>>>
>> Best solution is to do a proper restore of your complete pre-upgrade
>> database and let MythTV Do The Right Thing.
>>
> Looking back that is probably what I *should* have done, but I am not sure
> I'm up for that now - I spent most of a day setting up the new database,
> mostly because I wasn't satisfied with the old setup (non-standard
> keybindings,

can be reset to defaults by going into mythfrontend Utilities/Setup|Edit
Keys, then using MENU to select "Reset All Keys to Defaults" (
http://www.gossamer-threads.com/lists/mythtv/commits/487153#487153 ) on
any frontend whose key bindings you want to reset.

> bad tuner setup,

which could have been reset/cleared by using mythtv-setup to do a
"Delete all capture cards"

> flawed channel lists etc.).

and a "Delete all video sources" (not "Delete all video sources on
<hostname>").

> Going back would
> require me to do it all over again:-)

But would make the rest of your system function properly--and without
any concerns over the integrity of your database schema or data.

>> If you decide you want to waste hours re-configuring everything for no
>> benefit, at least do a proper partial restore:
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup (and take note of
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_when_upgrading_MythTV).
>>
> I already did reconfigure the entire setup and according to the links I
> would need to do some preparation on the old setup - obviously not possible
> now that the system is already upgraded:-(
>
> Guess I will have a closer look at the tables while I consider the
> "complete restore" option:-(

Right, I'm suggesting you either do a full restore--and then use MythTV
tools to clean up what you don't like--or start over with a supported
partial restore. I can't guarantee that HLS would work with your old
recordings if you do the partial restore using the restore script, but
at that point, I'd be motivated to help debug the issues, since I
wouldn't have any reason to assume your DB is corrupt.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


Spam1 at pontoppidan

May 30, 2012, 10:33 PM

Post #12 of 14 (1430 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

2012/5/30 Michael T. Dean <mtdean [at] thirdcontact>

> On 05/30/2012 03:03 AM, Thomas Pontoppidan wrote:
>
>> 2012/5/29 Michael T. Dean
>>
>> On 05/29/2012 03:36 AM, Thomas Pontoppidan wrote:
>>>
>>> During this weekend I finally chose to reinstall my backend - moving
>>>> from
>>>> an old Fedora install to MythBuntu. For different reasons I decided to
>>>> go
>>>> against recommendations and not move the entire database. I only
>>>> transferred my recordings following this guide
>>>> http://www.mythpvr.com/mythtv/**tips/migrate-recordings.html<http://www.mythpvr.com/mythtv/tips/migrate-recordings.html>
>>>> .
>>>>
>>>> Yes. Google should be kicked off the Internet for allowing that
>>> ancient,
>>> outdated, incorrect, can-corrupt-the-db-data (as it can completely break
>>> your character encoding) post to be #1.
>>>
>>
>> Well, I won't blame Google - after all it was my decision to not follow
>> official directions:-)
>>
>>
>> From a normal frontend the recordings are playing fine, but HLS doesn't
>>>
>>>> seem to work - I try to stream to Torc for IOS, but the "prepare stream"
>>>> stays at 0%. If I make a new recording it streams fine so I'm guessing
>>>> some
>>>> new fields in the recordings table are missing? Is there any way to add
>>>> the
>>>> missing info (if my assumption is correct) to the database?
>>>>
>>>> Best solution is to do a proper restore of your complete pre-upgrade
>>> database and let MythTV Do The Right Thing.
>>>
>>> Looking back that is probably what I *should* have done, but I am not
>> sure
>> I'm up for that now - I spent most of a day setting up the new database,
>> mostly because I wasn't satisfied with the old setup (non-standard
>> keybindings,
>>
>
> can be reset to defaults by going into mythfrontend Utilities/Setup|Edit
> Keys, then using MENU to select "Reset All Keys to Defaults" (
> http://www.gossamer-threads.**com/lists/mythtv/commits/**487153#487153<http://www.gossamer-threads.com/lists/mythtv/commits/487153#487153>) on any frontend whose key bindings you want to reset.
>
> bad tuner setup,
>>
>
> which could have been reset/cleared by using mythtv-setup to do a "Delete
> all capture cards"
>
> flawed channel lists etc.).
>>
>
> and a "Delete all video sources" (not "Delete all video sources on
> <hostname>").
>
>
> Going back would
>> require me to do it all over again:-)
>>
>
> But would make the rest of your system function properly--and without any
> concerns over the integrity of your database schema or data.
>
>
> If you decide you want to waste hours re-configuring everything for no
>>> benefit, at least do a proper partial restore:
>>> http://www.mythtv.org/wiki/**Database_Backup_and_Restore#**
>>> Partial_restore_of_a_backup<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup>(and take note of
>>> http://www.mythtv.org/wiki/**Database_Backup_and_Restore#**
>>> Partial_restore_when_**upgrading_MythTV<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_when_upgrading_MythTV>
>>> ).
>>>
>>> I already did reconfigure the entire setup and according to the links I
>> would need to do some preparation on the old setup - obviously not
>> possible
>> now that the system is already upgraded:-(
>>
>> Guess I will have a closer look at the tables while I consider the
>> "complete restore" option:-(
>>
>
> Right, I'm suggesting you either do a full restore--and then use MythTV
> tools to clean up what you don't like--or start over with a supported
> partial restore. I can't guarantee that HLS would work with your old
> recordings if you do the partial restore using the restore script, but at
> that point, I'd be motivated to help debug the issues, since I wouldn't
> have any reason to assume your DB is corrupt.


Thanks for your input - I will definitely use the proper procedure next
time! But this time I just can't imagine starting over after all the work
I've done:-)

Anyway, problem seems to be solved: I found a difference in paths in the
"livestream" table during HLS streaming - for new recordings it pointed to
the recording's real location while the old recording entry would point to
"myth:@"host-from-the-old-setup"/"file". After updating the hostname in the
recordings table and restarting mythbackend streaming works fine!


mtdean at thirdcontact

May 30, 2012, 11:23 PM

Post #13 of 14 (1426 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

On 05/31/2012 01:33 AM, Thomas Pontoppidan wrote:
> 2012/5/30 Michael T. Dean
>> On 05/30/2012 03:03 AM, Thomas Pontoppidan wrote:
>>> 2012/5/29 Michael T. Dean
>>>
>>> On 05/29/2012 03:36 AM, Thomas Pontoppidan wrote:
>>>> During this weekend I finally chose to reinstall my backend - moving
>>>>> During this weekend I finally chose to reinstall my backend - moving from
>>>>> an old Fedora install to MythBuntu. For different reasons I decided to
>>>>> go
>>>>> against recommendations and not move the entire database. I only
>>>>> transferred my recordings following this guide
>>>>> http://www.mythpvr.com/mythtv/**tips/migrate-recordings.html
>>>>> .
>>>> Yes. Google should be kicked off the Internet for allowing that
>>>> ancient,
>>>> outdated, incorrect, can-corrupt-the-db-data (as it can completely break
>>>> your character encoding) post to be #1.
>>>>
>>> Well, I won't blame Google - after all it was my decision to not follow
>>> official directions:-)
>>>>> From a normal frontend the recordings are playing fine, but HLS doesn't
>>>>> seem to work - I try to stream to Torc for IOS, but the "prepare stream"
>>>>> stays at 0%. If I make a new recording it streams fine so I'm guessing
>>>>> some
>>>>> new fields in the recordings table are missing? Is there any way to add
>>>>> the
>>>>> missing info (if my assumption is correct) to the database?
>>>> Best solution is to do a proper restore of your complete pre-upgrade
>>>> database and let MythTV Do The Right Thing.
>>> Looking back that is probably what I *should* have done, but I am not
>>> sure
>>> I'm up for that now - I spent most of a day setting up the new database,
>>> mostly because I wasn't satisfied with the old setup (non-standard
>>> keybindings,
>>>
>> can be reset to defaults by going into mythfrontend Utilities/Setup|Edit
>> Keys, then using MENU to select "Reset All Keys to Defaults" (
>> http://www.gossamer-threads.**com/lists/mythtv/commits/**487153#487153<http://www.gossamer-threads.com/lists/mythtv/commits/487153#487153>) on any frontend whose key bindings you want to reset.
>>
>>> bad tuner setup,
>>>
>> which could have been reset/cleared by using mythtv-setup to do a "Delete
>> all capture cards"
>>> flawed channel lists etc.).
>>>
>> and a "Delete all video sources" (not "Delete all video sources on
>> <hostname>").
>>
>>> Going back would
>>> require me to do it all over again:-)
>>>
>> But would make the rest of your system function properly--and without any
>> concerns over the integrity of your database schema or data.
>>
>>>> If you decide you want to waste hours re-configuring everything for no
>>>> benefit, at least do a proper partial restore:
>>>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup (and take note of
>>>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_when_upgrading_MythTV
>>>> ).
>>> I already did reconfigure the entire setup and according to the links I
>>> would need to do some preparation on the old setup - obviously not
>>> possible
>>> now that the system is already upgraded:-(
>>>
>>> Guess I will have a closer look at the tables while I consider the
>>> "complete restore" option:-(
>>>
>> Right, I'm suggesting you either do a full restore--and then use MythTV
>> tools to clean up what you don't like--or start over with a supported
>> partial restore. I can't guarantee that HLS would work with your old
>> recordings if you do the partial restore using the restore script, but at
>> that point, I'd be motivated to help debug the issues, since I wouldn't
>> have any reason to assume your DB is corrupt.
>
> Thanks for your input - I will definitely use the proper procedure next
> time! But this time I just can't imagine starting over after all the work
> I've done:-)
>
> Anyway, problem seems to be solved: I found a difference in paths in the
> "livestream" table during HLS streaming - for new recordings it pointed to
> the recording's real location while the old recording entry would point to
> "myth:@"host-from-the-old-setup"/"file". After updating the hostname in the
> recordings table and restarting mythbackend streaming works fine!

Meaning you changed your host name and didn't update your MythTV setup:

http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend

If you're comfortable believing that everything else--data and
schema--in your current DB is good and there's no other brokenness
(other than the loss of non-re-creatable information due to the broken
procedure you followed for the partial restore) and/or that you can
figure out and fix all the problems that crop up in the future (and you
believe that doing so will take less time than doing a full restore of
the pre-upgrade DB backup, changing hostname (as above), Delete All
Capture Cards, Delete All Video Sources, creating new cards and video
sources, connecting inputs, and scanning channels, then resetting key
bindings in mythfrontend...), I suppose I'm comfortable letting you run
with your not-as-good-as-it-should-be database. :) (Just saying that
you won't have the option to go back to your pre-upgrade database backup
for long, so now is the only opportunity...)

Anyway, glad you figured out this issue.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


Spam1 at pontoppidan

Jun 1, 2012, 5:40 AM

Post #14 of 14 (1410 views)
Permalink
Re: "Migrated" recordings from 0.24 won't stream via HLS [In reply to]

2012/5/31 Michael T. Dean <mtdean [at] thirdcontact>

> On 05/31/2012 01:33 AM, Thomas Pontoppidan wrote:
>
>> 2012/5/30 Michael T. Dean
>>
>>> On 05/30/2012 03:03 AM, Thomas Pontoppidan wrote:
>>>
>>>> 2012/5/29 Michael T. Dean
>>>>
>>>> On 05/29/2012 03:36 AM, Thomas Pontoppidan wrote:
>>>>
>>>>> During this weekend I finally chose to reinstall my backend - moving
>>>>>
>>>>>> During this weekend I finally chose to reinstall my backend - moving
>>>>>> from
>>>>>> an old Fedora install to MythBuntu. For different reasons I decided to
>>>>>> go
>>>>>> against recommendations and not move the entire database. I only
>>>>>> transferred my recordings following this guide
>>>>>> http://www.mythpvr.com/mythtv/****tips/migrate-recordings.html<http://www.mythpvr.com/mythtv/**tips/migrate-recordings.html>
>>>>>> .
>>>>>>
>>>>> Yes. Google should be kicked off the Internet for allowing that
>>>>> ancient,
>>>>> outdated, incorrect, can-corrupt-the-db-data (as it can completely
>>>>> break
>>>>> your character encoding) post to be #1.
>>>>>
>>>>> Well, I won't blame Google - after all it was my decision to not
>>>> follow
>>>> official directions:-)
>>>>
>>>>> From a normal frontend the recordings are playing fine, but HLS
>>>>>> doesn't
>>>>>> seem to work - I try to stream to Torc for IOS, but the "prepare
>>>>>> stream"
>>>>>> stays at 0%. If I make a new recording it streams fine so I'm guessing
>>>>>> some
>>>>>> new fields in the recordings table are missing? Is there any way to
>>>>>> add
>>>>>> the
>>>>>> missing info (if my assumption is correct) to the database?
>>>>>>
>>>>> Best solution is to do a proper restore of your complete pre-upgrade
>>>>> database and let MythTV Do The Right Thing.
>>>>>
>>>> Looking back that is probably what I *should* have done, but I am not
>>>> sure
>>>> I'm up for that now - I spent most of a day setting up the new database,
>>>> mostly because I wasn't satisfied with the old setup (non-standard
>>>> keybindings,
>>>>
>>>> can be reset to defaults by going into mythfrontend
>>> Utilities/Setup|Edit
>>> Keys, then using MENU to select "Reset All Keys to Defaults" (
>>> http://www.gossamer-threads.****com/lists/mythtv/commits/****
>>> 487153#487153<http://www.**gossamer-threads.com/lists/**
>>> mythtv/commits/487153#487153<http://www.gossamer-threads.com/lists/mythtv/commits/487153#487153>>)
>>> on any frontend whose key bindings you want to reset.
>>>
>>>
>>> bad tuner setup,
>>>>
>>>> which could have been reset/cleared by using mythtv-setup to do a
>>> "Delete
>>> all capture cards"
>>>
>>>> flawed channel lists etc.).
>>>>
>>>> and a "Delete all video sources" (not "Delete all video sources on
>>> <hostname>").
>>>
>>> Going back would
>>>> require me to do it all over again:-)
>>>>
>>>> But would make the rest of your system function properly--and without
>>> any
>>> concerns over the integrity of your database schema or data.
>>>
>>> If you decide you want to waste hours re-configuring everything for no
>>>>> benefit, at least do a proper partial restore:
>>>>> http://www.mythtv.org/wiki/**Database_Backup_and_Restore#**
>>>>> Partial_restore_of_a_backup<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup>(and take note of
>>>>> http://www.mythtv.org/wiki/**Database_Backup_and_Restore#**
>>>>> Partial_restore_when_**upgrading_MythTV<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_when_upgrading_MythTV>
>>>>> ).
>>>>>
>>>> I already did reconfigure the entire setup and according to the links I
>>>> would need to do some preparation on the old setup - obviously not
>>>> possible
>>>> now that the system is already upgraded:-(
>>>>
>>>> Guess I will have a closer look at the tables while I consider the
>>>> "complete restore" option:-(
>>>>
>>>> Right, I'm suggesting you either do a full restore--and then use MythTV
>>> tools to clean up what you don't like--or start over with a supported
>>> partial restore. I can't guarantee that HLS would work with your old
>>> recordings if you do the partial restore using the restore script, but at
>>> that point, I'd be motivated to help debug the issues, since I wouldn't
>>> have any reason to assume your DB is corrupt.
>>>
>>
>> Thanks for your input - I will definitely use the proper procedure next
>> time! But this time I just can't imagine starting over after all the work
>> I've done:-)
>>
>> Anyway, problem seems to be solved: I found a difference in paths in the
>> "livestream" table during HLS streaming - for new recordings it pointed to
>> the recording's real location while the old recording entry would point to
>> "myth:@"host-from-the-old-**setup"/"file". After updating the hostname
>> in the
>> recordings table and restarting mythbackend streaming works fine!
>>
>
> Meaning you changed your host name and didn't update your MythTV setup:
>
> http://www.mythtv.org/wiki/**Database_Backup_and_Restore#**
> Change_the_hostname_of_a_**MythTV_frontend_or_backend<http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend>
>
> If you're comfortable believing that everything else--data and schema--in
> your current DB is good and there's no other brokenness (other than the
> loss of non-re-creatable information due to the broken procedure you
> followed for the partial restore) and/or that you can figure out and fix
> all the problems that crop up in the future (and you believe that doing so
> will take less time than doing a full restore of the pre-upgrade DB backup,
> changing hostname (as above), Delete All Capture Cards, Delete All Video
> Sources, creating new cards and video sources, connecting inputs, and
> scanning channels, then resetting key bindings in mythfrontend...), I
> suppose I'm comfortable letting you run with your
> not-as-good-as-it-should-be database. :) (Just saying that you won't have
> the option to go back to your pre-upgrade database backup for long, so now
> is the only opportunity...)
>

I am comfortable believing that everything besides the migrated data is
good - after all, everything else is configured from scratch and the old
recordings will eventually be deleted.

I do get you subtle hint, but under the circumstances I would rather run
with my not-as-godd-as-it-should-be database than develop a
not-as-good-as-it-should-be relationship with my better half by spending
more time on the upgrade;-)

Thanks again!

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.