Paging should be used to break content into semantic or task-related groups of content, such as by your categories in your menu bar on the left. This allows users to find content by what it is (e.g., the page title in a menu) rather than where it is (e.g., page number or relative position in a scrolling page). Generally user tasks depend on what (“I need to check sports”) not where (“I need to check channels two-thirds down the list”).
Each page of related content may scroll. At one time, you couldn’t rely on nearly all users knowing how to scroll, so designers were advised to keep all content “above the fold.” That concern is largely gone now, and users are perfectly able and willing to scroll if there are signs the content they want is further down the page (although for the sake of efficiency, you still should put the content users want most at the top, such as provided by your sorting feature). [See Jakob Nielsen's article, "Scrolling and Attention."]
In your case, it looks like you’ve a list that is arbitrarily broken into pages. That is almost always inferior to putting everything in one large scrolling list. I’ve found scrolling to be about three times faster than paging for finding and comparing data in a table or list. More systematic research on search results (pretty close to what you have) found that pages of 50 items could be scanned through faster than pages of 10 items (100 items were apparently not significantly different than 50, but at that point, there were only two pages of results).
Scrolling has the following advantages over paging in lists and tables (not all necessarily apply in your case):
The scrollbar control is standardized so most users are already familiar with it. Paging lacks standardization so it takes attention and learning to use it (e.g., where in the page the links are located, whether there’s a First or Last link, whether there are links to selected individual pages).
The number of items shown can adjust automatically with window resizing, allowing users to optimize the number of items visible in one step and avoiding situations when there is both scrolling and paging.
The scrollbar is quickly accessible no matter where the user is in the window. Paging interfaces typically provide the page links at only the top and/or bottom of the page which can mean a long slew; they may even scroll out of view.
Users can move as little as one item at a time to show the items they want to see together. Paging splits items into arbitrary groups which can result in the items of interest being split across pages.
Users can scroll to anywhere in the list with a single drag. Paging is limited to the page links shown, generally limiting the user to move only around the immediate neighborhood.
Users can multi-select any set of items to perform an action on them (e.g., copying, deleting), and users can look at any other item while maintaining the current selection. Paging generally allows and maintains only selection of the items on the current page.
User sorting is less likely to result in disorientation. With scrolling you can leave the scroll position where it is or you can automatically scroll to “chase” the list item that currently has focus; either way users do okay. However, with paging, users can be disoriented when sorting changes everything on their current page or if their page number changes to some other value to keep the current item in focus. Many paging implementations (like yours) reset the user to Page 1 after sorting, which seems to avoid disorientation, but too often requires the user to re-navigate to a particular item.
Users can still move one “page” at a time anyway by clicking the “track” of the scrollbar.
I would recommend you put all your channels in a single scrolling pane. Put the channel list in a separate pane or frame from the menu and other general controls so they remain easy to access. Mixing paging and scrolling (e.g., 20 of 127 channels per page) may be worse than paging alone, forcing the user to decide when to do each, and sometimes they may need to do both (e.g., scroll up or down to the links to page). It looks like 127 channels is about 500kB to load in one page. Presumably your users have high-speed connections if they’re watching TV on the web, so you can count on the 500kB loading in only a few seconds.
Now 127 channels on a single page may appear to be "too many" to the user, so you may want to break them up within the page (e.g., putting in headers for "Today," "Yesterday," "Last Week" when sorted by Newest).
