Mailing List Archive

Video playback framerate
Hi Mark

Since you are getting deeply involved in video playback, I would like to
mention a couple of things I have done and what I would like to do.

1. AVSYNC

AVSYNC has some problems. It makes the assumption that video is fixed
frame rate (not always true) and that the rate matches what ffmpeg
supplies as the fps (not always true). If the frame rate differs from
what ffmpeg said, the audio sync will drop frames or double frame
intervals to get it back on time. There is also an "avsync predictor"
that attempts to smooth things out. I have seen cases where a few frames
per second are continuously being dropped on a high powered system that
is quite capable of keeping up.

I developed AVSYNC2 as a replacement for AVSYNC. At the moment it is
invoked by an advanced playback option, but I think it could replace
AVSYNC. AVSYNC2 relies on the timestamp of each frame to display the
frame at the correct time. I also added some code in the decoder
routines to fix incorrect timestamps when they occur. Also I fix
timestamps on deinterlace doubled frame rates when they are incorrect.

Everybody who has tried AVSYNC2 has give favorable feedback..

If we get rid of AVSYNC there is a lot of other code that can be
removed. The classes in vsync, the avsync predictor can probably be trashed.

2. Elapsed Time

The elapsed time of playback that is displayed in the information OSD
and used when skipping back or forward is something I would like to fix.
It works by taking the frame count, which gets calculated as playback
proceeds, and dividing by what it thinks the framerate is. If the
framerate is variable or the provided rate incorrect this results in
wrong values. I have seen playback where the time as measured on a
stopwatch diverges from the time as displayed by the OSD at the rate of
some 10 seconds every minute. MythTV can think playback is at the end
when there are still 10 minutes left. If there is no seek table, when
doing skip forward or back it converts its framecount back to a time
stamp for ffmpeg to jump to the desired location. This can give a wrong
result. In some cases doing a jump forward causes a jump backwards, in
other cases it jumps by the wrong amount.

I would like to change it throughout to use timestamp instead of frame
number for keeping track of the position. (I am not sure whether
timestamps ever get reset in the middle of a video and what to do about
that). Unfortunately this change would affect a lot of things, including
the seek table, which is currently indexed by frame number. It also
would affect commercial flagging and video editing, processing of cuts.

Peter


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On Fri, Jan 4, 2019, 8:48 PM Peter Bennett <pb.mythtv@gmail.com wrote:

> Hi Mark
>
> Since you are getting deeply involved in video playback, I would like to
> mention a couple of things I have done and what I would like to do.
>
> 1. AVSYNC
>
> Everybody who has tried AVSYNC2 has give favorable feedback..
>

To be honest, I've never really touched the a/v sync code because I never
had any issues with it and it seemed fragile (judging by the lengthy
discussions and number of tweaks and patches).

I have no issue with anything that is simpler and easier to maintain.

I assume you've tested it with all of the worst case scenarios - stream
change, broken audio, broken video, DVD, BD etc etc

The only request I'd make is - can it be moved/is it worth moving it into a
class of its own?

At the moment, MythPlayer is some 6000 lines of code - anything we can do
to farm out logic will help going forward.

If we get rid of AVSYNC there is a lot of other code that can be
> removed. The classes in vsync, the avsync predictor can probably be
> trashed.
>

Just remember that some of those vsync classes are - as the name suggests -
also performing sync to vblank to prevent tearing - though I'm not sure how
many playback methods actually need that these days.


> 2. Elapsed Time
>
> I would like to change it throughout to use timestamp instead of frame
> number for keeping track of the position. (I am not sure whether
> timestamps ever get reset in the middle of a video and what to do about
> that).
>

Again, this is not something I've ever really touched and haven't had any
issues with. But from experience, I don't believe it is an either/or
choice. Timestamps and frame number/key frame each have their advantages
and disadvantages - though I think timestamps are more universally useful
(audio only streams etc).

For recorded content, we really have no reason to get this wrong. We have
all of the information available at recording time.

I have no real understanding of the recorder classes and/or markup database
tables. Is there a simple way of adding time stamps as well? Would that
impact performance? How big are peoples databases currently running...

Presumably if we were to switch over to timestamps, we would need to run
duplicate/parallel tables for a release or 2 before switching over? So that
existing recordings would still work.

Or maybe write something to convert existing recordings over...

So many possibilities.

Regards
Mark
Re: Video playback framerate [ In reply to ]
On Mon, 7 Jan 2019 14:25:11 +0000, you wrote:

>How big are peoples databases currently running...

I have a monster database. So increasing the size of the recordedseek
table would have a big impact on me:

root@mypvr:/var/lib/mysql# du -h mythconverg
14G mythconverg

root@mypvr:/var/lib/mysql# du -h mythconverg/*
4.0K mythconverg/archiveitems.frm
0 mythconverg/archiveitems.MYD
4.0K mythconverg/archiveitems.MYI
16K mythconverg/bdbookmark.frm
0 mythconverg/bdbookmark.MYD
4.0K mythconverg/bdbookmark.MYI
4.0K mythconverg/callsignnetworkmap.frm
0 mythconverg/callsignnetworkmap.MYD
4.0K mythconverg/callsignnetworkmap.MYI
8.0K mythconverg/capturecard.frm
8.0K mythconverg/capturecard.MYD
4.0K mythconverg/capturecard.MYI
4.0K mythconverg/cardinput.frm
0 mythconverg/cardinput.MYD
4.0K mythconverg/cardinput.MYI
8.0K mythconverg/channel.frm
4.0K mythconverg/channelgroup.frm
4.0K mythconverg/channelgroup.MYD
4.0K mythconverg/channelgroup.MYI
4.0K mythconverg/channelgroupnames.frm
4.0K mythconverg/channelgroupnames.MYD
4.0K mythconverg/channelgroupnames.MYI
36K mythconverg/channel.MYD
32K mythconverg/channel.MYI
8.0K mythconverg/channel_new.frm
4.0K mythconverg/channel_new.MYD
12K mythconverg/channel_new.MYI
4.0K mythconverg/channelscan_channel.frm
4.0K mythconverg/channelscan_channel.MYD
4.0K mythconverg/channelscan_channel.MYI
4.0K mythconverg/channelscan_dtv_multiplex.frm
4.0K mythconverg/channelscan_dtv_multiplex.MYD
4.0K mythconverg/channelscan_dtv_multiplex.MYI
4.0K mythconverg/channelscan.frm
4.0K mythconverg/channelscan.MYD
4.0K mythconverg/channelscan.MYI
4.0K mythconverg/codecparams.frm
8.0K mythconverg/codecparams.MYD
8.0K mythconverg/codecparams.MYI
4.0K mythconverg/crashed_names.frm
96K mythconverg/crashed_names.ibd
4.0K mythconverg/credits.frm
0 mythconverg/credits.MYD
4.0K mythconverg/credits.MYI
60K mythconverg/customexample.frm
4.0K mythconverg/customexample.MYD
4.0K mythconverg/customexample.MYI
4.0K mythconverg/db.opt
4.0K mythconverg/diseqc_config.frm
0 mythconverg/diseqc_config.MYD
4.0K mythconverg/diseqc_config.MYI
4.0K mythconverg/diseqc_tree.frm
4.0K mythconverg/diseqc_tree.MYD
4.0K mythconverg/diseqc_tree.MYI
4.0K mythconverg/displayprofilegroups.frm
4.0K mythconverg/displayprofilegroups.MYD
8.0K mythconverg/displayprofilegroups.MYI
4.0K mythconverg/displayprofiles.frm
16K mythconverg/displayprofiles.MYD
24K mythconverg/displayprofiles.MYI
4.0K mythconverg/dtv_multiplex.frm
4.0K mythconverg/dtv_multiplex.MYD
4.0K mythconverg/dtv_multiplex.MYI
4.0K mythconverg/dtv_privatetypes.frm
4.0K mythconverg/dtv_privatetypes.MYD
4.0K mythconverg/dtv_privatetypes.MYI
8.0K mythconverg/dvdbookmark.frm
76K mythconverg/dvdbookmark.MYD
8.0K mythconverg/dvdbookmark.MYI
4.0K mythconverg/dvdinput.frm
4.0K mythconverg/dvdinput.MYD
4.0K mythconverg/dvdinput.MYI
4.0K mythconverg/dvdtranscode.frm
4.0K mythconverg/dvdtranscode.MYD
4.0K mythconverg/dvdtranscode.MYI
4.0K mythconverg/eit_cache.frm
28K mythconverg/eit_cache.MYD
28K mythconverg/eit_cache.MYI
4.0K mythconverg/filemarkup.frm
400K mythconverg/filemarkup.MYD
328K mythconverg/filemarkup.MYI
4.0K mythconverg/gallery_directories.frm
0 mythconverg/gallery_directories.MYD
4.0K mythconverg/gallery_directories.MYI
8.0K mythconverg/gallery_files.frm
15M mythconverg/gallery_files.MYD
1.6M mythconverg/gallery_files.MYI
4.0K mythconverg/gallerymetadata.frm
4.0K mythconverg/gallerymetadata.MYD
8.0K mythconverg/gallerymetadata.MYI
12K mythconverg/gamemetadata.frm
0 mythconverg/gamemetadata.MYD
4.0K mythconverg/gamemetadata.MYI
8.0K mythconverg/gameplayers.frm
0 mythconverg/gameplayers.MYD
4.0K mythconverg/gameplayers.MYI
4.0K mythconverg/housekeeping.frm
4.0K mythconverg/housekeeping.MYD
4.0K mythconverg/housekeeping.MYI
4.0K mythconverg/inputgroup.frm
4.0K mythconverg/inputgroup.MYD
4.0K mythconverg/inputgroup.MYI
8.0K mythconverg/internetcontentarticles.frm
0 mythconverg/internetcontentarticles.MYD
4.0K mythconverg/internetcontentarticles.MYI
4.0K mythconverg/internetcontent.frm
0 mythconverg/internetcontent.MYD
4.0K mythconverg/internetcontent.MYI
4.0K mythconverg/inuseprograms.frm
4.0K mythconverg/inuseprograms.MYD
8.0K mythconverg/inuseprograms.MYI
4.0K mythconverg/iptv_channel.frm
16K mythconverg/iptv_channel.MYD
4.0K mythconverg/iptv_channel.MYI
4.0K mythconverg/jobqueue.frm
0 mythconverg/jobqueue.MYD
4.0K mythconverg/jobqueue.MYI
4.0K mythconverg/jumppoints.frm
8.0K mythconverg/jumppoints.MYD
8.0K mythconverg/jumppoints.MYI
4.0K mythconverg/keybindings.frm
60K mythconverg/keybindings.MYD
24K mythconverg/keybindings.MYI
4.0K mythconverg/keyword.frm
12K mythconverg/keyword.MYD
16K mythconverg/keyword.MYI
12K mythconverg/livestream.frm
0 mythconverg/livestream.MYD
4.0K mythconverg/livestream.MYI
12K mythconverg/logging.frm
0 mythconverg/logging.MYD
4.0K mythconverg/logging.MYI
4.0K mythconverg/movies_movies.frm
0 mythconverg/movies_movies.MYD
4.0K mythconverg/movies_movies.MYI
4.0K mythconverg/movies_showtimes.frm
0 mythconverg/movies_showtimes.MYD
4.0K mythconverg/movies_showtimes.MYI
4.0K mythconverg/movies_theaters.frm
0 mythconverg/movies_theaters.MYD
4.0K mythconverg/movies_theaters.MYI
4.0K mythconverg/music_albumart.frm
4.0K mythconverg/music_albumart.MYD
4.0K mythconverg/music_albumart.MYI
4.0K mythconverg/music_albums.frm
4.0K mythconverg/music_albums.MYD
12K mythconverg/music_albums.MYI
4.0K mythconverg/music_artists.frm
4.0K mythconverg/music_artists.MYD
12K mythconverg/music_artists.MYI
4.0K mythconverg/music_directories.frm
4.0K mythconverg/music_directories.MYD
4.0K mythconverg/music_directories.MYI
4.0K mythconverg/music_genres.frm
4.0K mythconverg/music_genres.MYD
12K mythconverg/music_genres.MYI
4.0K mythconverg/music_playlists.frm
4.0K mythconverg/music_playlists.MYD
4.0K mythconverg/music_playlists.MYI
12K mythconverg/music_radios.frm
128K mythconverg/music_radios.ibd
4.0K mythconverg/music_smartplaylist_categories.frm
4.0K mythconverg/music_smartplaylist_categories.MYD
8.0K mythconverg/music_smartplaylist_categories.MYI
4.0K mythconverg/music_smartplaylist_items.frm
4.0K mythconverg/music_smartplaylist_items.MYD
4.0K mythconverg/music_smartplaylist_items.MYI
4.0K mythconverg/music_smartplaylists.frm
4.0K mythconverg/music_smartplaylists.MYD
8.0K mythconverg/music_smartplaylists.MYI
12K mythconverg/music_songs.frm
24K mythconverg/music_songs.MYD
36K mythconverg/music_songs.MYI
4.0K mythconverg/music_stats.frm
0 mythconverg/music_stats.MYD
4.0K mythconverg/music_stats.MYI
12K mythconverg/music_streams.frm
18M mythconverg/music_streams.ibd
4.0K mythconverg/mythexport.frm
4.0K mythconverg/mythexport_job_queue.frm
96K mythconverg/mythexport_job_queue.ibd
0 mythconverg/mythexport.MYD
4.0K mythconverg/mythexport.MYI
52K mythconverg/mythlog.frm
56K mythconverg/mythlog.MYD
12K mythconverg/mythlog.MYI
8.0K mythconverg/mythsgu_archived.frm
2.1M mythconverg/mythsgu_archived.ibd
4.0K mythconverg/mythsgu_move.frm
580K mythconverg/mythsgu_move.ibd
4.0K mythconverg/mythweb_sessions.frm
104K mythconverg/mythweb_sessions.MYD
12K mythconverg/mythweb_sessions.MYI
4.0K mythconverg/networkiconmap.frm
0 mythconverg/networkiconmap.MYD
4.0K mythconverg/networkiconmap.MYI
4.0K mythconverg/oldfind.frm
4.0K mythconverg/oldfind.MYD
4.0K mythconverg/oldfind.MYI
4.0K mythconverg/oldprogram.frm
920K mythconverg/oldprogram.MYD
756K mythconverg/oldprogram.MYI
56K mythconverg/oldrecorded_export.frm
72K mythconverg/oldrecorded_export.MYD
104K mythconverg/oldrecorded_export.MYI
56K mythconverg/oldrecorded.frm
15M mythconverg/oldrecorded.MYD
14M mythconverg/oldrecorded.MYI
4.0K mythconverg/people.frm
288K mythconverg/people.MYD
384K mythconverg/people.MYI
4.0K mythconverg/phonecallhistory.frm
0 mythconverg/phonecallhistory.MYD
4.0K mythconverg/phonecallhistory.MYI
4.0K mythconverg/phonedirectory.frm
4.0K mythconverg/phonedirectory.MYD
4.0K mythconverg/phonedirectory.MYI
4.0K mythconverg/pidcache.frm
0 mythconverg/pidcache.MYD
4.0K mythconverg/pidcache.MYI
4.0K mythconverg/playgroup.frm
4.0K mythconverg/playgroup.MYD
4.0K mythconverg/playgroup.MYI
52K mythconverg/powerpriority.frm
4.0K mythconverg/powerpriority.MYD
4.0K mythconverg/powerpriority.MYI
48K mythconverg/powerpriority_tmp.frm
96K mythconverg/powerpriority_tmp.ibd
4.0K mythconverg/profilegroups.frm
4.0K mythconverg/profilegroups.MYD
12K mythconverg/profilegroups.MYI
60K mythconverg/program.frm
4.0K mythconverg/programgenres.frm
3.7M mythconverg/programgenres.MYD
2.4M mythconverg/programgenres.MYI
24M mythconverg/program.MYD
19M mythconverg/program.MYI
4.0K mythconverg/programrating.frm
272K mythconverg/programrating.MYD
328K mythconverg/programrating.MYI
4.0K mythconverg/real_names.frm
96K mythconverg/real_names.ibd
4.0K mythconverg/recgrouppassword.frm
0 mythconverg/recgrouppassword.MYD
4.0K mythconverg/recgrouppassword.MYI
4.0K mythconverg/recgroups.frm
4.0K mythconverg/recgroups.MYD
4.0K mythconverg/recgroups.MYI
4.0K mythconverg/recordedartwork.frm
0 mythconverg/recordedartwork.MYD
4.0K mythconverg/recordedartwork.MYI
4.0K mythconverg/recordedcredits.frm
16K mythconverg/recordedcredits.MYD
28K mythconverg/recordedcredits.MYI
8.0K mythconverg/recordedfile.frm
1.3M mythconverg/recordedfile.MYD
500K mythconverg/recordedfile.MYI
60K mythconverg/recorded.frm
4.0K mythconverg/recordedmarkup.frm
8.6M mythconverg/recordedmarkup.MYD
9.4M mythconverg/recordedmarkup.MYI
11M mythconverg/recorded.MYD
3.1M mythconverg/recorded.MYI
56K mythconverg/recordedprogram.frm
6.6M mythconverg/recordedprogram.MYD
2.4M mythconverg/recordedprogram.MYI
4.0K mythconverg/recordedrating.frm
788K mythconverg/recordedrating.MYD
1.2M mythconverg/recordedrating.MYI
4.0K mythconverg/recordedseek.frm
7.0G mythconverg/recordedseek.MYD
6.4G mythconverg/recordedseek.MYI
4.0K mythconverg/recordfilter.frm
4.0K mythconverg/recordfilter.MYD
4.0K mythconverg/recordfilter.MYI
56K mythconverg/record.frm
4.0K mythconverg/recordingprofiles.frm
4.0K mythconverg/recordingprofiles.MYD
4.0K mythconverg/recordingprofiles.MYI
4.0K mythconverg/recordmatch.frm
56K mythconverg/recordmatch.MYD
148K mythconverg/recordmatch.MYI
820K mythconverg/record.MYD
356K mythconverg/record.MYI
52K mythconverg/record_tmp.frm
2.0M mythconverg/record_tmp.ibd
8.0K mythconverg/romdb.frm
0 mythconverg/romdb.MYD
4.0K mythconverg/romdb.MYI
4.0K mythconverg/scan_channels.frm
112K mythconverg/scan_channels.ibd
4.0K mythconverg/scannerfile.frm
0 mythconverg/scannerfile.MYD
4.0K mythconverg/scannerfile.MYI
4.0K mythconverg/scannerpath.frm
0 mythconverg/scannerpath.MYD
4.0K mythconverg/scannerpath.MYI
4.0K mythconverg/schemalock.frm
0 mythconverg/schemalock.MYD
4.0K mythconverg/schemalock.MYI
52K mythconverg/settings.frm
36K mythconverg/settings.MYD
32K mythconverg/settings.MYI
52K mythconverg/settings_old.frm
24K mythconverg/settings_old.MYD
28K mythconverg/settings_old.MYI
4.0K mythconverg/storagegroup.frm
4.0K mythconverg/storagegroup.MYD
12K mythconverg/storagegroup.MYI
4.0K mythconverg/tvchain.frm
0 mythconverg/tvchain.MYD
4.0K mythconverg/tvchain.MYI
4.0K mythconverg/tvosdmenu.frm
4.0K mythconverg/tvosdmenu.MYD
4.0K mythconverg/tvosdmenu.MYI
12K mythconverg/upnpmedia.frm
2.3M mythconverg/upnpmedia.MYD
1.3M mythconverg/upnpmedia.MYI
4.0K mythconverg/user_permissions.frm
0 mythconverg/user_permissions.MYD
4.0K mythconverg/user_permissions.MYI
4.0K mythconverg/user_sessions.frm
4.0K mythconverg/user_sessions.MYD
8.0K mythconverg/user_sessions.MYI
4.0K mythconverg/users.frm
4.0K mythconverg/users.MYD
8.0K mythconverg/users.MYI
4.0K mythconverg/videocast.frm
12K mythconverg/videocast.MYD
8.0K mythconverg/videocast.MYI
4.0K mythconverg/videocategory.frm
0 mythconverg/videocategory.MYD
4.0K mythconverg/videocategory.MYI
8.0K mythconverg/videocollection.frm
0 mythconverg/videocollection.MYD
4.0K mythconverg/videocollection.MYI
4.0K mythconverg/videocountry.frm
4.0K mythconverg/videocountry.MYD
4.0K mythconverg/videocountry.MYI
4.0K mythconverg/videogenre.frm
4.0K mythconverg/videogenre.MYD
4.0K mythconverg/videogenre.MYI
4.0K mythconverg/videometadatacast.frm
8.0K mythconverg/videometadatacast.MYD
12K mythconverg/videometadatacast.MYI
4.0K mythconverg/videometadatacountry.frm
4.0K mythconverg/videometadatacountry.MYD
4.0K mythconverg/videometadatacountry.MYI
8.0K mythconverg/videometadata.frm
4.0K mythconverg/videometadatagenre.frm
4.0K mythconverg/videometadatagenre.MYD
12K mythconverg/videometadatagenre.MYI
9.2M mythconverg/videometadata.MYD
2.0M mythconverg/videometadata.MYI
4.0K mythconverg/videopart.frm
0 mythconverg/videopart.MYD
4.0K mythconverg/videopart.MYI
4.0K mythconverg/videopathinfo.frm
0 mythconverg/videopathinfo.MYD
4.0K mythconverg/videopathinfo.MYI
16K mythconverg/videosource.frm
4.0K mythconverg/videosource.MYD
8.0K mythconverg/videosource.MYI
4.0K mythconverg/videotypes.frm
4.0K mythconverg/videotypes.MYD
4.0K mythconverg/videotypes.MYI
4.0K mythconverg/weatherdatalayout.frm
128K mythconverg/weatherdatalayout.ibd
4.0K mythconverg/weatherscreens.frm
96K mythconverg/weatherscreens.ibd
4.0K mythconverg/weathersourcesettings.frm
96K mythconverg/weathersourcesettings.ibd
4.0K mythconverg/websites.frm
96K mythconverg/websites.ibd

root@mypvr:/var/lib/mysql# ll
/mnt/savaidh/ldrive/Backups/MythTV_db_backup/mypvr/
total 10670204
drwxrwxrwx 2 root root 0 Jan 8 10:02 ./
drwxrwxrwx 2 root root 12288 Aug 2 16:42 ../
-rwxrwxrwx 1 root root 2182641092 Jan 4 09:45
mythconverg-1348-20190104094148.sql.gz*
-rwxrwxrwx 1 root root 2183823426 Jan 5 09:45
mythconverg-1348-20190105094209.sql.gz*
-rwxrwxrwx 1 root root 2184524470 Jan 6 09:45
mythconverg-1348-20190106094217.sql.gz*
-rwxrwxrwx 1 root root 2186685665 Jan 7 09:43
mythconverg-1348-20190107094011.sql.gz*
-rwxrwxrwx 1 root root 2188589221 Jan 8 09:45
mythconverg-1348-20190108094156.sql.gz*
drwxrwxrwx 2 root root 0 Jul 17 05:40 old/

MariaDB [mythconverg]> select count(*) from recorded;
+----------+
| count(*) |
+----------+
| 31486 |
+----------+
1 row in set (0.00 sec)

MariaDB [mythconverg]> select count(*) from recordedseek;
+-----------+
| count(*) |
+-----------+
| 296906976 |
+-----------+
1 row in set (0.00 sec)
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On 8 January 2019 1:28:41 pm Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Mon, 7 Jan 2019 14:25:11 +0000, you wrote:
>
>> How big are peoples databases currently running...
>
> I have a monster database. So increasing the size of the recordedseek
> table would have a big impact on me:
>
> root@mypvr:/var/lib/mysql# du -h mythconverg
> 14G mythconverg

14G, of which 13.4G is recordedseek table alone.


> 4.0K mythconverg/recordedseek.frm
> 7.0G mythconverg/recordedseek.MYD
> 6.4G mythconverg/recordedseek.MYI



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On Tue, 8 Jan 2019, at 10:36, Mark Perkins wrote:

> > root@mypvr:/var/lib/mysql# du -h mythconverg
> > 14G mythconverg
>
> 14G, of which 13.4G is recordedseek table alone.

Good grief!!!

george@tvbox:/var/lib/mysql$ sudo du -h mythconverg
166M mythconverg
Re: Video playback framerate [ In reply to ]
On Tue, 8 Jan 2019, at 10:40, George Poulson wrote:
> Good grief!!!
>
> george@tvbox:/var/lib/mysql$ sudo du -h mythconverg
> 166M mythconverg
>

Somehow the last line of my reply got deleted...

Your 14GB database is bigger than my system disk :-o
Re: Video playback framerate [ In reply to ]
On Tue, 8 Jan 2019 10:33:29 +0000, you wrote:

>On 8 January 2019 1:28:41 pm Stephen Worthington <stephen_agent@jsw.gen.nz>
>wrote:
>
>> On Mon, 7 Jan 2019 14:25:11 +0000, you wrote:
>>
>>> How big are peoples databases currently running...
>>
>> I have a monster database. So increasing the size of the recordedseek
>> table would have a big impact on me:
>>
>> root@mypvr:/var/lib/mysql# du -h mythconverg
>> 14G mythconverg
>
>14G, of which 13.4G is recordedseek table alone.
>
>
>> 4.0K mythconverg/recordedseek.frm
>> 7.0G mythconverg/recordedseek.MYD
>> 6.4G mythconverg/recordedseek.MYI

Yes, that is the way it works. In most databases, most of the storage
is used in the recordedseek table. I should also say that I am not
opposed to changes to recordedseek - it is one of the good things
about MythTV as it makes skipping about in recordings work
excellently, and improving that is a good thing. I just want everyone
to be aware of the potential for problems with databases as large as
mine. Imagine how long a schema update might take if all of my
recordedseek had to be converted to a new format. And it would be
dramatically worse if all of my recordings needed to be rescanned to
do it - how long would it take to just read 65 Tbytes of data, let
alone do processing on it?
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On 1/8/19 10:34 AM, Stephen Worthington wrote:
> On Tue, 8 Jan 2019 10:33:29 +0000, you wrote:
>
>> On 8 January 2019 1:28:41 pm Stephen Worthington <stephen_agent@jsw.gen.nz>
>> wrote:
>>
>>> On Mon, 7 Jan 2019 14:25:11 +0000, you wrote:
>>>
>>>> How big are peoples databases currently running...
>>> I have a monster database. So increasing the size of the recordedseek
>>> table would have a big impact on me:
>>>
>>> root@mypvr:/var/lib/mysql# du -h mythconverg
>>> 14G mythconverg
>> 14G, of which 13.4G is recordedseek table alone.
>>
>>
>>> 4.0K mythconverg/recordedseek.frm
>>> 7.0G mythconverg/recordedseek.MYD
>>> 6.4G mythconverg/recordedseek.MYI
> Yes, that is the way it works. In most databases, most of the storage
> is used in the recordedseek table. I should also say that I am not
> opposed to changes to recordedseek - it is one of the good things
> about MythTV as it makes skipping about in recordings work
> excellently, and improving that is a good thing. I just want everyone
> to be aware of the potential for problems with databases as large as
> mine. Imagine how long a schema update might take if all of my
> recordedseek had to be converted to a new format. And it would be
> dramatically worse if all of my recordings needed to be rescanned to
> do it - how long would it take to just read 65 Tbytes of data, let
> alone do processing on it?
>
Point taken, we will not make any changes that require recreating the
seek table. I would prefer to get rid of the seek table, but I don't
know if that can happen.

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On Mon, 2019-01-07 at 14:25 +0000, Mark Kendall wrote:
>
> Presumably if we were to switch over to timestamps, we would need to
> run duplicate/parallel tables for a release or 2 before switching
> over? So that existing recordings would still work.

Does waiting a release or two help? I have recordings which are older
than that[0]. Is there some housekeeping thing which will "refresh" the
seek table for all recordings over the lifetime of a release?

Ian.

[0] my oldest recording is from 2011 (and, slightly implausible I know,
is something I really do intend to watch at some point...) there's also
some recorded movies (which still get rewatched) of a similar vintage.


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
2011? My wife’s oldest recordings are from 2007 !




> On 9 Jan 2019, at 3:08 am, Ian Campbell <ijc@hellion.org.uk> wrote:
>
> ...
> [0] my oldest recording is from 2011 (and, slightly implausible I know,
> is something I really do intend to watch at some point...) there's also
> some recorded movies (which still get rewatched) of a similar vintage.

--
Nigel Pearson, 02 8576 5449, 0408 66 44 35
nigel.pearson.au@gmail.com
Re: Video playback framerate [ In reply to ]
On Wed, Jan 09, 2019 at 06:57:44AM +1100, Nigel Pearson wrote:
> 2011? My wife’s oldest recordings are from 2007 !

Mine too. 2007 is the oldest here. Back when I had 120GB disk in the
machine, rather than 24TB...

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
Astonishing! All our recordings have auto expire on, we hide watched
programmes, and I have a script to set recordings to watched if they
haven't been watched within 90 days.

And even then navigating through the recordings can get tedious. How on
earth do you guys find anything amongst a decade's worth of television?!

Surely there's a point where you should transcode those chestnuts and put
them in your video library.

On Wed, 9 Jan 2019, 7:15 AM Lennart Sorensen <lsorense@csclub.uwaterloo.ca
wrote:

> On Wed, Jan 09, 2019 at 06:57:44AM +1100, Nigel Pearson wrote:
> > 2011? My wife’s oldest recordings are from 2007 !
>
> Mine too. 2007 is the oldest here. Back when I had 120GB disk in the
> machine, rather than 24TB...
>
> --
> Len Sorensen
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: Video playback framerate [ In reply to ]
On Wed, 9 Jan 2019 08:27:23 +1100, you wrote:

>Astonishing! All our recordings have auto expire on, we hide watched
>programmes, and I have a script to set recordings to watched if they
>haven't been watched within 90 days.
>
>And even then navigating through the recordings can get tedious. How on
>earth do you guys find anything amongst a decade's worth of television?!
>
>Surely there's a point where you should transcode those chestnuts and put
>them in your video library.

Why transcode? That only reduces the quality of a recording. You can
just move the file directly to a videos directory (and rename it
appropriately) if you really think it is better off as a video file.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On Tue, 8 Jan 2019 11:01:54 -0500, you wrote:

>
>
>On 1/8/19 10:34 AM, Stephen Worthington wrote:
>> On Tue, 8 Jan 2019 10:33:29 +0000, you wrote:
>>
>>> On 8 January 2019 1:28:41 pm Stephen Worthington <stephen_agent@jsw.gen.nz>
>>> wrote:
>>>
>>>> On Mon, 7 Jan 2019 14:25:11 +0000, you wrote:
>>>>
>>>>> How big are peoples databases currently running...
>>>> I have a monster database. So increasing the size of the recordedseek
>>>> table would have a big impact on me:
>>>>
>>>> root@mypvr:/var/lib/mysql# du -h mythconverg
>>>> 14G mythconverg
>>> 14G, of which 13.4G is recordedseek table alone.
>>>
>>>
>>>> 4.0K mythconverg/recordedseek.frm
>>>> 7.0G mythconverg/recordedseek.MYD
>>>> 6.4G mythconverg/recordedseek.MYI
>> Yes, that is the way it works. In most databases, most of the storage
>> is used in the recordedseek table. I should also say that I am not
>> opposed to changes to recordedseek - it is one of the good things
>> about MythTV as it makes skipping about in recordings work
>> excellently, and improving that is a good thing. I just want everyone
>> to be aware of the potential for problems with databases as large as
>> mine. Imagine how long a schema update might take if all of my
>> recordedseek had to be converted to a new format. And it would be
>> dramatically worse if all of my recordings needed to be rescanned to
>> do it - how long would it take to just read 65 Tbytes of data, let
>> alone do processing on it?
>>
>Point taken, we will not make any changes that require recreating the
>seek table. I would prefer to get rid of the seek table, but I don't
>know if that can happen.

If the recordedseek table could be done away with, without sacrificing
any of the seek performance, then that would be a very good thing. The
size of recordedseek is a pain in so many ways. But the seek
performance is a key feature of MythTV, so I would not want to see any
degradation of that at all.

If it was necessary to rescan everything and recreate the seek data,
that would be possible, but would take some careful planning. I think
it would require keeping the old recordedseek table around and in
read-only use until all the recordings had been converted to use the
new seek data. There would have to be a background task that was
running converting the old recordings, and it would have to be
completely robust and restartable as it would be running for so long
that it would be inevitable that MythTV and/or the entire PC would
need to be shut down at some time during the process. And the
possibility (probability?) of a power failure or other catastrophic
crash during the process would need to be accounted for. There would
likely need to be a mechanism to pause the scanning so that database
backups could be done safely.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On Wed, 9 Jan 2019, at 03:05, Stephen Worthington wrote:

> >Surely there's a point where you should transcode those chestnuts and put
> >them in your video library.
>
> Why transcode? That only reduces the quality of a recording. You can
> just move the file directly to a videos directory (and rename it
> appropriately) if you really think it is better off as a video file.

Yep - that's what I do - there's nothing more than a few months old in my mythtv system/database - any recordings worth saving are moved elsewhere (which has the additional advantage of avoiding any accidental deletions as well as keeping the myth recordings menu easy to navigate).
George
Re: Video playback framerate [ In reply to ]
On 09/01/2019 09:16, George Poulson wrote:
> On Wed, 9 Jan 2019, at 03:05, Stephen Worthington wrote:
>
>> >Surely there's a point where you should transcode those chestnuts and put
>> >them in your video library.
>>
>> Why transcode?  That only reduces the quality of a recording.  You can
>> just move the file directly to a videos directory (and rename it
>> appropriately) if you really think it is better off as a video file.
>
> Yep - that's what I do - there's nothing more than a few months old in
> my mythtv system/database - any recordings worth saving are moved
> elsewhere (which has the additional advantage of avoiding any accidental
> deletions as well as keeping the myth recordings menu easy to navigate).
> George


This is moving towards user-list territory, but the thread started as a
plea for retaining seektables. I rely on the seektable for cutting both
video and audio recordings, but eventually the output files get moved
out of the Recordings groups and their seektables vanish. Videos can
have seektables, but TTBOMK these have to be rebuilt. Does Stephen, in
particular, keep all his library as Recordings? Or rebuild by default?
Perhaps he has said before, but I'm curious.

I see that I currently have 2216 recordings occupying 2.2 TB.
Optimizing and defragging the seektables both take around 140 seconds.

John P


John P




_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On 09/01/2019 02:27, Stephen Worthington wrote:
> On Wed, 9 Jan 2019 08:27:23 +1100, you wrote:
>
>> Astonishing! All our recordings have auto expire on, we hide watched
>> programmes, and I have a script to set recordings to watched if they
>> haven't been watched within 90 days.
>>
>> And even then navigating through the recordings can get tedious. How on
>> earth do you guys find anything amongst a decade's worth of television?!
>>
>> Surely there's a point where you should transcode those chestnuts and put
>> them in your video library.
>
> Why transcode? That only reduces the quality of a recording. You can
> just move the file directly to a videos directory (and rename it
> appropriately) if you really think it is better off as a video file.

*lossless* transcode is great for removing commercials,
whilst still keeping the broadcast quality.

However currently only works for mpeg2 content and not
the newer formats which HD tends to be broadcast in


Regards
Stuart
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Video playback framerate [ In reply to ]
On Wed, 9 Jan 2019 11:04:05 +0000, you wrote:

>On 09/01/2019 09:16, George Poulson wrote:
>> On Wed, 9 Jan 2019, at 03:05, Stephen Worthington wrote:
>>
>>> >Surely there's a point where you should transcode those chestnuts and put
>>> >them in your video library.
>>>
>>> Why transcode?? That only reduces the quality of a recording.? You can
>>> just move the file directly to a videos directory (and rename it
>>> appropriately) if you really think it is better off as a video file.
>>
>> Yep - that's what I do - there's nothing more than a few months old in
>> my mythtv system/database - any recordings worth saving are moved
>> elsewhere (which has the additional advantage of avoiding any accidental
>> deletions as well as keeping the myth recordings menu easy to navigate).
>> George
>
>
>This is moving towards user-list territory, but the thread started as a
>plea for retaining seektables. I rely on the seektable for cutting both
>video and audio recordings, but eventually the output files get moved
>out of the Recordings groups and their seektables vanish. Videos can
>have seektables, but TTBOMK these have to be rebuilt. Does Stephen, in
>particular, keep all his library as Recordings? Or rebuild by default?
>Perhaps he has said before, but I'm curious.
>
>I see that I currently have 2216 recordings occupying 2.2 TB.
>Optimizing and defragging the seektables both take around 140 seconds.

I do not move recordings to videos. Doing that does away with the
advantages of having recordedseek entries for the recording. I have
never tried using seek table for videos. Performance in seeking in my
ripped or downloaded video files is normally fine anyway. But I do
not have many very high bit rate videos - my HD recordings are usually
the highest bit rate files I play.

Recordings are normally MPEG Transport Stream files, and I suspect
that they are not organised for best seeking due to the requirements
of being robust in the face of loss of data when there are problems
receiving the signal. Video files (ripped, downloaded, ...) are
normally in a container format that does good seeking (MPEG Program
Stream, AVI, .mp4, MKV, MOV, ...). So I think that if you move
recordings to videos, you should probably do a lossless transcode that
just changes the container format from transport stream to program
stream. But I have never delved far enough into the details of the
container formats to know that for sure.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org